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1.  Introduction 

This  Feasibility  Analysis  Study  report  describes  the  results  of  a  small  ADST II 
study  effort  to  examine  the  feasibility  of  a  Generic  Instructor  Operator  Station 
(GIOS)  for  use  on  US  Army  engagement  simulators.  We  have  focused  on  three 
specific  STRICOM  programs:  AGTS,  CCTT,  and  AVCATT,  with  emphasis  on  the 
first  two  because  of  a  lack  of  hard  requirements  for  AVCATT.  Our  approach  has 
been  to  re-engineer  the  AGTS  lOS  such  that  it  could  be  added  to  CCTT  or  AGTS  as 
a  DIS  compatible  device  to  support  structured  gunnery  training.  Further,  we  have 
addressed  the  inclusion  of  semi-automated  Instructor  Operator  (10)  functions  to 
give  each  10  a  greater  span  of  control,  with  the  goal  of  reducing  10  manpower 
requirements  significantly. 

The  main  benefit  of  this  concept,  if  implemented,  would  be  the  ability  to  add  a 
structured,  precision  gunnery  capability  to  the  inherent  tactical  training  capability 
of  the  CCTT  program.  We  see  no  reason  why  this  concept  should  not  extend  to 
future  CATT  devices  as  well,  with  the  appropriate  tailoring.  Another  benefit  is  the 
reduction  in  manpower  required  to  perform  the  10  functions.  Currently  AGTS  can 
require  as  many  as  five  Instructors  and  four  Operators  to  support  platoon  gunnery 
exercises;  our  goal  is  to  reduce  this  to  a  single  10. 

The  impact  of  adding  a  GIOS  to  the  target  systems  is  addressed.  We  point  out  that 
a  GIOS  by  itself  is  necessary  but  not  sufficient  to  allow  CCTT  to  support  precision 
gunnery;  other  issues  such  as  scene  update  rate  and  training  data  requirements 
also  come  into  play. 

The  FAS  report  is  organized  as  follows:  Background  (Section  2),  Objectives  (Section 
3),  Approach  (Section  4),  Data  Collection  (Section  5),  System  Design  (Section  6), 
Potential  Follow-On  Activities  (Section  7),  Summary  (Section  8),  and  References 
(Section  9).  Figure  1-1  illustrates  the  overall  development  process. 


Figure  1-1:  Overall  Approach 

The  follow-on  activities,  if  implemented,  would  logically  fall  into  two  phases,  as 


gioscdrl.doc 


1 


ADST-II-CDRL-029R-9600263 
September  13, 1996 


shown:  a  stand-alone  prototype  implementation  first  phase  to  prove  the  concept 
from  an  engineering  standpoint,  followed  by  a  user  oriented  evaluation  phase  via 
integration  and  test  of  a  prototype  GIOS  with  a  CCTT  M1A2  Quick  Start  module  in 
the  OSF. 

Any  questions  or  comments  regarding  this  FAS  should  be  addressed  to  Bob 
Ferguson  or  Brian  Plamondon  at  Lockheed  Martin: 

•  Bob  Ferguson:  407-306-4382,  bob_ferguson@ccmail.orl.mmc.com 

•  Brian  Plamondon:  407-306-4226,  brian_d_plamondon@ccmail.orl.mmc.com 

We  also  acknowledge  the  contributions  of  Thurman  Autrey  and  John  Schlott  to  this 
report. 

2.  Background 

Individual  and  crew  training  systems  for  DoD  have  traditionally  employed 
dedicated  Instructor  Operator  Stations.  For  many  years  the  prevailing  wisdom  has 
been  that  one  Instructor  Operator  and  one  lOS  per  crew  station  is  required  to 
achieve  effective  training.  Precision  gunnery  trainers  from  COFT  (Conduct  of  Fire 
Trainer)  to  PGT  (Platoon  Gunnery  Trainer)  and  now  AGTS  (Advanced  Gunnery 
Training  System)  have  required  dedicated  instructors  and  dedicated  lOS’s  [ref  1]. 
Whereas  these  systems  extend  to  platoon  level,  the  training  emphasis  is  at  the 
individual  and  crew  level. 

SIMNET  introduced  large  scale  collective  training  capabilities  into  DoD.  SIMNET 
and  its  successor  CCTT  are  aimed  at  force-on-force  free  play  exercises  at  the 
platoon,  company,  and  battalion  levels,  in  contrast  to  the  AGTS  highly  structured 
individual  and  crew  gunnery  trainers  [ref  2] .  These  systems  do  not  require  1  on  1 
instruction,  nor  do  they  utilize  Instructor  Operator  Stations.  Rather,  a  single 
battlemaster  working  at  a  Master  Control  Console  (MCC)  oversees  one  or  more 
exercises,  which  are  typically  comprised  of  a  number  of  crew  stations,  SAF  stations 
and  other  assets  networked  together. 

AGTS  capitalized  on  the  requirement  for  dedicated  lOS’s  by  embedding  the  lOS 
with  the  host  computer  system.  This  design  approach  was  taken  to  minimize 
recurring  costs  to  the  overall  program.  In  addition  to  servicing  the  lOS,  the  host 
computer  also  serves  as  the  interface  to  the  crew  station  and  to  the  DIS  network. 

It  has  been  argued  by  some  that  the  AGTS  lOS  should  have  been  broken  out  from 
the  crew  station  as  a  separable  DIS  asset  in  order  to  be  compliant  to  DIS  standards. 
The  counter-argument  is  that  since  an  lOS  is  required  for  every  crew  trainer,  there 
is  no  reason  to  add  cost  to  the  system  just  to  make  it  a  stand-alone  DIS  device. 
There  is  no  DIS  architectural  construct  we  are  aware  of  that  requires  a  stand-alone 
lOS. 

However,  there  are  other  reasons  to  evolve  the  AGTS  lOS  into  a  networkable  asset. 
For  one,  STRICOM  has  expressed  an  interest  in  adding  a  structured  gunnery 
training  capability  to  CCTT  and  subsequent  CATT  devices.  Another  reason  is  to 
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reduce  the  manpower  required  to  support  the  training  systems;  for  example,  if  an 
AGTS  lOS  could  be  designed  stand-alone  such  that  one  instructor  could  oversee  two 
or  more  crew  stations,  then  fewer  lOS  devices  and  fewer  lO’s  would  be  needed.  It  is 
noteworthy  that  this  requirement  for  stand-alone,  networkable  lOS  devices  for 
gunnery  trainers  has  already  appeared  in  RFP’s  issued  by  overseas  users. 

From  a  CCTT  perspective,  a  modular,  networkable  lOS  would  offer  the  potential  to 
add  a  structured  gunnery  training  capability  to  CCTT  systems.  It  should  also  be 
possible  to  extend  this  training  enhancement  across  the  entire  CATT  family  of 
simulators  with  the  appropriate  tailoring.  This  need  is  foreshadowed  by  the 
AVCATT  Operational  Requirements  Document  (ORD),  which  calls  out  the 
requirement  for  an  lOS  [ref  3] . 

3.  Objectives 

The  overall  objective  of  this  Feasibility  Analysis  Study  is  to  develop  the 
requirements  and  design  concepts  for  a  Generic  Instructor  Operator  Station  (GIOS) 
for  US  Army  engagement  simulators.  The  FAS  is  directed  at  engagement 
simulators  for  direct  fire  ground  to  ground  and  air  to  ground  applications.  Three 
target  programs  have  been  selected  as  the  potential  beneficiaries  of  this  study:  the 
Advanced  Gunnery  Training  System  (AGTS),  the  Close  Combat  Tactical  Trainer 
(CCTT),  and  the  Aviation  Combined  Arms  Tactical  Trainer  (AVCATT). 

More  specifically,  the  primary  objective  of  this  study  is  the  development  of  a  design 
concept  for  a  DIS  compliant,  stand-alone  networkable  asset  that  is  reconfigurable 
via  software  and/or  data  changes  to  meet  the  range  of  applications  indicated. 

Although  DIS  compliance  is  a  primary  requirement  because  the  GIOS  is  initially 
targeted  at  legacy  DIS  systems,  the  design  should  also  allow  for  migration  to  HLA 
systems  in  the  future.  Further,  the  GIOS  should  not  be  constrained  to  one  10  per 
trainer  or  crew;  rather,  the  intent  is  to  develop  a  design  concept  that  will  support  a 
user  specified  ratio  of  Instructor  Operators  to  trainees  (i.e.,  1  to  N).  This  will 
necessitate  the  minimizing  of  instructional  functions  such  as  crew  monitoring  and 
operator  functions  such  as  surrogate  driver  and  loader  functions  to  the  extent 
practicable. 

The  output  of  this  FAS  is  this  report,  which  describes  the  requirements  and  a 
preliminary  design  approach  for  a  GIOS.  Potential  follow-on  activities  are  also 
described. 

4.  Approach 

In  order  to  keep  the  study  manageable  and  within  budget  we  limited  the  initial 
scope  of  the  study  to  ground  to  ground  and  air  to  ground  direct  fire  applications.  In 
particular,  we  focused  on  three  target  programs:  AGTS,  CCTT,  and  AVCATT.  The 
intent  is  that  the  GIOS  design  disclosed  herein  will  be  applicable  to  all  three 
programs.  The  benefit  to  AGTS  would  be  reduced  manpower  requirements  for 
instructors  and/or  operators,  and  the  benefit  to  the  CATT  programs  would  be  the 
introduction  of  a  structured  training  instructional  program  for  direct  fire  to 
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complement  the  inherent  tactical  training  capability. 

In  addition,  we  have  leveraged  data  collection  efforts  for  the  AC-130U  and  ARMS 
(Aviation  Reconfigurable  Manned  Simulator)  Delivery  Orders  to  pick  up 
requirements  for  fixed  and  rotary  wing  aircraft.  A  potential  follow-on  effort  would 
extend  the  study  to  encompass  indirect  fire  (FSCATT)  and  air  defense  applications 
(ADCATT).  This  is  discussed  in  paragraph  7.3.1. 

We  have  constrained  the  functionality  of  the  GIOS  within  fairly  traditional  bounds  - 
that  is,  instructor  operator  (10)  monitoring  and  control  of  crew  and  platoon  level 
exercises.  Extension  to  regimes  above  platoon  is  discussed  in  paragraph  7.3.2  as  a 
possible  follow-on  activity.  We  do  not  advocate  expansion  of  the  lOS  role  to 
encompass  After  Action  Review  or  Battlemaster  functionality,  or  to  replace  these  or 
other  existing  GATT  assets  with  an  all-  encompassing  universal  10  Station. 

Rather,  the  intent  is  that  the  GIOS  be  treated  as  an  additional  and  complementary 
training  asset  to  the  GATT  sub-systems.  This  issue  is  dealt  with  in  paragraph  6.4.1, 
as  well  as  paragraphs  7.3.3.  and  7.3.4. 

Figure  4-1  illustrates  the  current  architecture  for  the  AGTS  when  it  is  fielded  in 
platoon  mode  as  a  DIS  compliant  system. 


One  lOS  is  dedicated  per  crew  station  in  current  gunnery  training  systems  like 
AGTS  and  PGT;  CCTT  currently  does  not  require  an  lOS 

Figure  4-1;  Gurrent  AGTS  Platoon  Architecture 

Note  that  there  is  one  lOS  per  crew  station,  and  that  it  interfaces  directly  with  the 
crew  station  as  opposed  to  the  DIS  network.  Further,  there  is  a  PrebriefiAfter 
Action  Review  (PAAR)  device  connected  as  a  DIS  asset  to  the  network.  A  SAFOR  is 
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currently  not  required  for  AGTS;  enemy  vehicle  movement  is  scripted  and 
controlled  by  the  host  computer.  However,  some  interest  has  been  expressed  in 
adding  intelligent  targets  to  AGTS,  and  this  has  triggered  the  initiation  of  trade 
studies  to  investigate  how  a  SAFOR  could  be  added  to  the  network.  Overseas  users 
of  AGTS-like  devices  have  requested  that  a  SAFOR  be  included  with  the  training 
device.  (Note:  a  prototype  SAF  capability  was  recently  integrated  and  successfully 
demonstrated  with  an  overseas  platoon  gunnery  trainer). 

Figure  4-2  illustrates  a  potential  future  architecture  for  platoon  level  training  for 
AGTS  and  GATT  type  devices. 


PAAR  (AGTS)  or 
AAR  (CCTT) 


MCC/MC 

(CCTT) 


AVCATT  and  new  gunnery  trainers  now  on  the  drawing  boards  require  a  Generic 
iOS  as  a  separate,  networkable  asset;  provides  easy  reconfiguration  of  system 
and  human  resources.  The  goal  is  one  GIOS  for  a  platoon  or  a  section. 

Figure  4-2:  Future  AGTS/CATT  Platoon  Architecture 

A  Generic  IOS  is  shown  as  a  stand-alone  networkable  device,  with  an  interface  to 
the  DIS  network.  The  other  components  remain  the  same.  By  making  the  GIOS  a 
networkable  asset,  it  becomes  possible  to  reduce  the  number  of  lO’s  per  crew 
station,  if  crew  10  workloads  are  sufficiently  automated.  It  also  becomes  possible  to 
add  a  GIOS  to  an  existing  CCTT  system  to  add  precision  gunnery  training 
capabilities.  This  is  not  to  say  that  the  GIOS  is  sufficient  by  itself;  there  are  other 
issues  such  as  scene  update  rate  that  also  need  to  be  addressed  [ref  4],  but  a  GIOS 
is  a  necessary  condition.  The  impact  of  a  GIOS  on  legacy  systems  like  CCTT  and 
AGTS  is  discussed  in  detail  in  paragraphs  6.4.1  and  6.4.2,  respectively.  As  noted 
earlier,  AVCATT,  a  future  CATT  system,  calls  out  a  requirement  for  an  IOS  in 
addition  to  the  standard  CCTT  devices  (MCC,  AAR). 

Table  4-1  lists  the  functions  of  such  a  GIOS  and  contrasts  it  with  the  existing 
Instructor  Operator  devices  shown  -  the  IOS  as  exemplified  by  the  current  AGTS 
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lOS,  the  MCC  as  exemplified  by  the  CCTT  MCC/MC,  and  the  AAR  as  exemplified 
by  the  PAAR  in  AGTS  and  the  AAR  in  CCTT. 


Table  4-1:  GIOS  Requirements  versus  lOS,  MCC  and 

AAR  in  AGTS  and  CCTT 

lOS 

GIOS 

MCC 

PAAR/AAR 

System  &  Exercise 

Initialization 

X 

X 

X 

Exercise  Monitoring  &  Control 

X 

X 

X 

-  Start/stop/freeze/resume 

X 

X 

X 

-  Environmental  conditions 

X 

X 

X 

-  System/Exercise  Status 

X 

X 

X 

-  Situation  Monitor 

X 

text 

-  Plan  View  Display 

liHiil 

X 

all  modes 

X 

static 

X 

-  3D  Display 

X 

repeaters, 
crew  &  pn  level 

X 

stealth,  crew  & 
platoon  level 

X 

stealth,  pn  & 

CO  level  (AAR 
only) 

-  Data  Record/Playback 

X 

video  +  audio 
tape 

X 

DIS  (data  + 
voice) 

-  Data  Extraction 

X 

built-in 

X 

will  impact 
target  sims 

-  Ownvehicle  Movement 

Ctrl 

-  Target  Movement  Ctrl 
(SAPOR  provides  free 
movement) 

X 

Scripted 

X 

Scripted+free 

Training  Management 

X 

X 

-  Training  Matrix 

X 

X 

-  Student  Records 

X 

X 

X 

X 

X 

Detailed  Student  Critiques 

X 

This  table  previews  and  summarizes  the  requirements  analysis  presented  in 
Section  5.2.3.  The  reason  for  showing  this  table  here  is  to  provide  an  overall 
context  for  the  GIOS,  and  to  bound  its  scope.  The  GIOS  is  not  intended  to  replace 
an  AAR  or  an  MCC,  although  much  of  the  functionality  overlaps  these  devices,  as 
shown.  Rather,  the  GIOS  is  intended  to  complement  the  existing  AGTS  and  CCTT 
designs  to  the  extent  practical.  This  issue  is  dealt  with  further  in  paragraph  6.4, 
Integration  with  Legacy  Systems. 

Finally,  in  order  to  better  understand  the  potential  impact  of  a  GIOS  on  the  current 
AGTS-type  training  manpower  profile.  Figure  4-3  is  offered  to  illustrate  potential 
manpower  benefits  for  a  system  containing  a  GIOS. 
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Figure  4-3:  Potential  GIOS  Training  Mode  Combinations 

This  figure  shows  the  various  training  modes  possible  with  up  to  4  crew  stations 
networked  together.  Here  we  make  the  assumption  that  one  GIOS  can  handle  a 
crew  station,  a  section,  or  a  platoon;  thus,  the  design  for  the  GIOS  must  reduce  the 
10  workload  sufficiently  to  make  this  possible.  This  is  one  of  the  major  goals  of  the 
project. 

Note  that  each  lOS  has  associated  with  it  one  10  and  one  or  more  role  players, 
which  is  meant  to  indicate  either  a  driver  or  loader  for  a  ground  vehicle  or  a  pilot 
for  an  air  vehicle.  In  the  case  of  AGTS,  a  driver  (either  the  actual  crew  member  or  a 
role  player)  would  sit  in  front  of  a  CRT  and  navigate  with  a  joystick;  in  CCTT,  the 
driver  would  be  an  actual  crew  member  in  a  simulated  driver  compartment. 
Eliminating  the  need  for  a  (human)  driver  is  required  to  achieve  the  manpower 
reduction  indicated.  In  the  case  of  CCTT,  the  human  driver  may  be  present,  but  the 
design  should  allow  for  the  case  when  the  driver  is  not  available.  We  envision  an 
automated  driver  function,  which  responds  to  commander  spoken  commands  just  as 
a  real  driver  would,  with  a  terrain  reasoning  capability  similar  to  that  provided 
with  existing  SAF  simulations. 

We  believe  that  the  second  column  shown  in  the  figure  (“Step  1”)  is  achievable  via 
the  incorporation  of  Natural  Language  Processing  (NLP)  and  crew  performance 
monitoring  software.  The  NLP  capability  supports  elimination  of  the  role  players, 
and  the  crew  monitoring  capability  eliminates  the  need  for  a  human  10  at  every 
crew  station  for  section  and  platoon  exercises.  As  shown,  in  the  platoon  mode  the 
desired  manpower  reduction  is  8:1.  We  believe  that  this  is  within  the  capabilities  of 
todays  commercially  available  technology. 

The  more  difficult  task  is  reducing  the  manpower  requirements  to  the  levels  shown 
in  the  third  column  (“Step  2”).  One  10  assigned  to  two  crew  stations  running 
independent  crew  level  exercises  will  necessitate  the  introduction  of  an  automated 
coach  or  tutor  function.  This  might  be  implemented  with  an  intelligent  tutoring 
agent  of  some  sort.  This  should  be  contrasted  with  the  higher  echelon  training 
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modes  (section  and  platoon)  where  the  trainees  presumably  have  already  passed 
crew  level  training  programs,  thus  minimizing  the  need  for  remedial  interaction 
(coaching)  between  the  10  and  the  crew.  Intelligent  tutoring  poses  a  much  larger 
technical  challenge  than  the  more  passive  “crew  monitoring  function”  mentioned 
above,  and  the  payback  in  terms  of  10  manpower  reductions  is  comparatively  low, 
therefore  we  suggest  that  this  be  tackled  at  a  future  date. 

The  GIOS  is  intended  to  support  individual,  crew,  section,  and  platoon  level 
gunnery  training  exercises  using  either  CCTT  or  AGTS  assets.  Extension  to  higher 
echelons  is  somewhat  problematic  since  it  brings  into  play  a  simultaneous 
requirement  for  tactical  training.  A  combined  “tactical-gunnery”  trainer  would 
require  smart  targets  that  can  fight  back  and  take  evasive  action,  as  well  as 
increased  tactical  choices  for  the  platoon  and  company  leaders.  Whether  or  not 
these  tactical  decisions  should  even  be  subjected  to  computerized  scoring  methods  is 
an  open  question,  since  there  will  often  not  be  one  “right”  approach  for  a  given 
situation  [ref  5].  Nevertheless,  there  appears  to  be  an  emerging  demand  for  a 
Company  level  tactical-gunnery  training  device.  This  issue  is  further  dealt  with  in 
paragraph  7.3.2. 

We  do  believe  that  the  approach  described  herein  should  be  readily  extendible  to 
support  mixed  operations  -  that  is,  a  portion  of  the  networked  devices  could  be 
executing  tactical  training,  while  another  portion  of  the  networked  devices  was 
executing  precision  gunnery.  This  should  be  simply  a  matter  of  system  set-up  and 
resource  allocation. 

The  following  two  sections  discuss  the  project  as  two  overlapping  phases:  Data 
Collection  (5)  and  System  Design  (6). 

5.  Data  Collection 

5.1  Introduction 

The  GIOS  FAS  data  collection  effort  was  undertaken  to  determine  lOS 
reqvurements  fi"om  three  major  sources:  1)  candidate  systems  of  interest  (AGTS, 
CCTT,  and  AVCATT)  and  related  systems;  2)  specific  training  system  program 
requirements;  and  3)  general  user  training  reqvurements.  Initial  plans  were  to 
conduct  on-site  user/SME  interviews  and  lOS  system  observations  at  training  sites 
including  Forts  Knox,  Hood,  and  Stewart.  However,  study  funding  limitations 
caused  these  trips  to  be  deleted  from  the  data  collection  effort  to  be  replaced  as 
necessary  with  telephone  calls  and  opportunistic  discussions  with  SMEs  visiting 
Orlando  in  support  of  other  training  simulator  programs  such  as  AGTS.  Data 
collection  efforts  on  the  principle  systems  of  interest  are  documented  in  the 
following  sections.  The  results  of  the  data  analysis  effort  are  presented  in  Section 
5.2. 

5.1.1  AGTS 

Work  previously  performed  by  one  of  the  GIOS  study  principals  on  AGTS  lOS 
requirements  analysis  was  extended  and  served  as  a  major  source  of  data  for  AGTS 
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[ref  6].  This  effort  included  site  visits  to  Forts  Einox  and  Hood  in  late  1994,  where 
SMEs  were  interviewed  about  current  lOS  strengths  and  weaknesses  and  what 
they  would  like  to  see  in  future  lOS  implementations.  lOS  operations  during  crew 
and  platoon  training  sessions  were  observed  to  collect  information  on  10  task 
loading  and  information  requirements.  The  results  of  this  effort  were  documented 
in  internal  AGTS  reports  [ref  7,  8].  Training  program  descriptions  were  derived 
from  internal  AGTS  design  documents  [ref  9]  and  concept  white  papers  [ref  10,  11], 
with  additional  personal  communications  with  the  primary  authors. 

5.1.2  CCTT 

CCTT  information  was  obtained  primarily  from  system  requirements  and 
description  documentation  [ref  2, 12, 13, 14].  A  visit  to  the  heritage  Loral  Federal 
Systems  development  facility  in  Orlando  was  made  to  observe  the  CCTT  equipment 
and  conduct  discussions  with  engineering  personnel. 

5.1.3  AVCATT 

Little  data  was  found  on  the  AVCATT  program.  All  information  on  requirements 
for  this  system  were  obtained  from  the  AVCATT  ORD  (Operational  Requirements 
Document)  [ref  3]. 

5.1.4  AC-130U 

Attempts  were  also  made  to  leverage  work  performed  on  the  ADST  II AC-130U 
delivery  order,  where  trips  were  made  to  several  fixed-  and  rotary-wing  aircraft 
training  facilities,  including  Ft.  Campbell,  to  assess  training  and  lOS  requirements 
and  capabilities.  Unfortunately,  hard  training  requirements  were  not  available. 
However,  eight  different  lOS  product  configurations  were  evaluated  and 
recommendations  have  been  made  by  the  Training  Product  Development  Team 
(PDT)  for  the  AC-130U  Navigation/Fire  Control  Officer  (Nav/FCO)  Testbed  lOS  [ref 
15]. 

5.1.5  Training  Requirements  Data  Collection 

GIOS  training  program  and  data  requirements  were  principally  derived  from  AGTS 
crew  and,  to  a  lesser  extent,  platoon  training  programs.  Source  data  includes 
internal  LMIS  training  analysis  and  requirements  definition  documentation 
generated  on  the  AGTS  program  [ref  16, 17],  and  discussions  with  the  personnel 
responsible  for  developing  the  training  programs.  Army  training  and  field  manuals 
[ref  18,  19]  were  reviewed  to  define  at  a  relatively  high  level  the  training 
requirements  of  the  systems  of  interest  for  this  study.  The  outcome  of  this 
comparison  is  presented  in  the  following  section. 

5.2  Data  Collection  Findings 

5.2.1  Training  Requirements 

Relevant  U.S.  Army  Training  and  Evaluation  Programs  (ARTEPs)  and  field 
manuals  [ref  18,  19]  were  reviewed  to  categorize  and  compare  the  training 
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requirements  of  the  two  major  systems  under  consideration  for  this  study  -  AGTS 
and  CCTT.  The  outcome  of  this  comparison  is  presented  in  Table  5.2. 1-1. 
Requirements  stated  or  inferred  for  AVCATT  and  AC-130U  programs  are  also 
presented  in  the  table  for  comparative  purposes. 

Table  5.2. 1-1:  Training  Simulator  Requirements  Comparison 


TRAINING  AND  EVALUATION 
REQUIREMENTS 

AGTS 

CCTT 

AVCATT 

AC-130U 

CREW  LEVEL  TRAINING 

X 

X 

X 

SCORING 

Graded  Tank 
Table  VII  FM 
17-12>1 

TBD 

TBD 

ARTEP  Training  Missions: 

MANEUVER/TACTICS 

X 

X 

X 

JOINT  COLLECTIVE  TASK 
DEFENSE/OFFENSE 
SCENARIOS 

X 

X 

X 

FIRE  SUPPORT 

X 

X 

X 

MOBILITY/COUNTER¬ 

MOBILITY/SURVIVABILITY 

X 

X 

X 

CREW  COORDINATION 

X 

X 

X 

1.  TC 

X 

2.  GUNNER 

X 

3.  LOADER 

Simulate 

d 

4.  DRIVER 

Simulate 

d 

PRECISION  GUNNERY 

X 

X 

1.  TC 

X 

2.  GUNNER 

X 

3.  LOADER 

Simulate 

d 

4.  DRIVER 

Simulate 

d 

PLATOON/SECTION  LEVEL 
TRAINING 

X 

X 

X 

X 

SCORING 

Graded 
platoon  Tank 
table  XII; 

Go/No  Go 

Go/NoGo 

TBD 

TBD 

ARTEP  Training  Missions: 

MANEUVER/TACTICS 

X 

X 

X 

X 

COLLECTIVE  TASK 
DEFENSE/OFFENSE 
SCENARIOS 

X 

X 

X 

X 

FIRE  SUPPORT 

X 

X 

X 

X 

MOBILITY/COUNTER¬ 

MOBILITY/SURVIVABILITY 

X 

X 

X 

X 
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TRAINING  AND  EVALUATION 
REQUIREMENTS 

AGTS 

CCTT 

AVCATT 

AC-130U 

AIR  DEFENSE 

X 

X 

X 

COMBAT  SUPPORT 

X 

X 

X 

CREW  COORDINATION 

X 

X 

X 

X 

1.  TC 

X 

X 

2.  GUNNER 

X 

X 

3.  LOADER 

Simulate 

d 

X 

4.  DRIVER 

Simulate 

d 

X 

PRECISION  GUNNERY 

X 

1.  TC 

X 

2.  GUNNER 

X 

3.  LOADER 

Simulate 

d 

4.  DRIVER 

Simulate 

d 

COMPANY/TEAM  LEVEL 

TRAINING 

X 

X 

X 

SCORING 

Go/NoGo 

TBD 

TBD 

ARTEP  Training  Missions: 

MANEUVERA'ACTICS 

X 

X 

X 

COLLECTIVE  TASK 
DEFENSE/OFFENSE 
SCENARIOS 

X 

X 

X 

FIRE  SUPPORT 

X 

X 

X 

MOBILITY/COUNTER¬ 

MOBILITY/SURVIVABILITY 

X 

X 

X 

AIR  DEFENSE 

X 

X 

X 

COMBAT  SUPPORT 

X 

X 

X 

CREW  COORDINATION 

X 

X 

X 

1.  TC 

X 

2.  GUNNER 

X 

3.  LOADER 

X 

4.  DRIVER 

X 

PRECISION  GUNNERY 

N/A 

N/A 

N/A 

As  can  be  seen  in  the  table,  the  AGTS  and  CCTT  training  missions  are  largely 
complementary,  with  some  degree  of  redundancy  in  Platoon/Section  level  training 
requirements  (except  for  precision  gunnery).  The  impact  of  these  different 
requirements  can  be  seen  in  the  nature  of  the  training  programs  and  performance 
scoring  implementations  on  AGTS  versus  CCTT,  and  in  the  data  requirements  to 
support  the  AGTS  scoring  algorithms  (see  Section  5.2.2). 

It  should  be  noted  that  the  fact  that  there  is  no  formal  requirement  for  a  system  to 
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support  a  specific  level  of  training  does  not  mean  that  the  system  provides  no 
training  value  for  that  level.  For  example,  CCTT’s  mission  is  not  currently  to 
provide  crew  level  training  during  its  exercises.  However,  the  crew  of  a  simulated 
vehicle  obviously  derives  some  training  benefit  during  the  execution  of  company  or 
higher  level  exercises.  Drivers  maneuver  their  vehicles  over  terrain  using  high- 
fidelity  controls  and  displays.  TCs  ensure  that  their  vehicle  supports  their  portion 
of  the  mission  objectives;  gunners  operate  their  systems  and  fire  at  targets,  and  the 
loader  participates  as  well.  Thus,  the  crew  at  a  minimum  can  obtain  some  skill 
sustainment  training  (presuming  they  are  performing  their  tasks  correctly).  The 
difference  is  that  a  system  such  as  AGTS  supports  crew  training  (for  the  TC  and 
gunner)  with  specific,  well-defined,  repeatable,  objective  performance  measures 
against  which  crew  performance  can  be  evaluated  and  tracked  over  repeated 
training  sessions.  CCTT  crew  performance  evaluation  is  pass/fail  assessment  of 
how  well  they  and  their  platoon,  company,  etc.  supported  the  overall  mission 
objectives. 

CCTT  is  anticipating  incorporating  the  SAMUTA  “packaged”  training  approach  to 
develop  predefined  missions  to  give  the  observer/controller  a  more  structured 
performance  assessment  environment  and  methodology.  However,  the  impact  of 
this  to  CCTT  is  more  in  structuring  the  training  mission  and  developing  the 
software  packages  rather  than  imposing  data  extraction  and  scoring  algorithm 
development  requirements 

The  training  programs  used  on  AGTS  and  the  training  system  defined  for  CCTT  are 
described  below.  The  majority  of  the  description  is  on  AGTS  since  it  has  well- 
defined  training  programs.  This  is  intended  to  provide  a  general  overview  and  to 
introduce  concepts  that  will  be  useful  in  understanding  Scoring  Data  Requirements 
defined  in  Section  5.2.2  and  GIGS  system  requirements  presented  in  Section  5.2.3. 

5.2. 1.1  AGTS  Training  Programs 

5.2. 1.1.1  Crew  Training 

AGTS  as  crew  trainer  supports  precision  gunnery  training  of  one  commander  and 
gunner  in  a  crewstation  that  replicates  the  turret  of  their  weapon  system.  Each 
trainer  is  configured  as  a  simulator  system  and  an  instructional  system.  The 
simulator  system  provides  the  functional  and  physical  means  to  perform  the 
individual  tasks  and  crew  duties  required.  The  instructional  system  presents 
exercises  and  scenarios,  provides  performance  measurement  and  feedback,  and 
supports  the  data  analysis  needed  by  the  Instructor  Operator  (10). 

Crew  exercises  vary  in  level  of  difficulty  to  provide  training  tailored  to  the 
proficiency  of  the  crewmembers.  In  general,  each  exercise  is  designed  so  the  firing 
vehicle  can  see  and  have  the  opportunity  to  destroy  all  vehicles  presented  during 
the  exercise.  The  targets  are  grouped  into  “situations”  for  presentation  during  the 
exercise.  The  number  of  targets  in  a  situation  varies  from  1  to  4  based  on  the  level 
of  difficulty  of  the  exercise.  Each  exercise  contains  between  10  and  20  targets 
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grouped  into  between  5  and  10  situations. 

Level  of  difficulty  is  also  determined  by  the  position  of  targets  and  firing  vehicles. 
The  firing  vehicle  can  be  either  moving  or  stationary.  Targets  can  also  be  either 
moving  or  stationary.  The  crew  training  program  uses  pre-programmed  paths  for 
both  targets  and  firing  vehicles  to  ensure  concentration  of  precision  gunnery  skills 
under  controlled  conditions. 

The  crew  receives  specific  instructions  for  each  exercise.  These  instructions 
describe  the  training  objective  and  the  conditions  under  which  the  crew  will 
operate.  Conditions  include  visibility,  malfunctions,  battlesight  range,  target  type 
and  quantity,  and  other  parameters  necessary  to  support  practice  on  the  training 
objective. 

The  duration  of  a  crew  training  program  exercise  is  about  10  to  15  minutes.  After 
each  exercise,  the  instructor  is  provided  performance  analysis  information  to 
support  critique  of  the  crew’s  performance.  Progression  between  exercises  is 
controlled  by  computer  recommendation  or  by  10  exercise  selection.  The  normal 
training  session  lasts  from  1  to  2  hours.  A  hardcopy  session  summary  provides 
information  for  debrief  and  pre-brief  of  subsequent  training  sessions. 

5.2. 1.1.2  Platoon  Training 

The  AGTS  platoon  training  program  is  still  under  development,  but  is  expected  to 
follow  the  model  of  predecessor  platoon  gunnery  training  systems.  The  initial 
platoon  training  mission  is  to  train  M1A2  platoon  gunnery  tasks  and  procedures 
while  conducting  tactical  maneuver  operations  in  support  of  offensive  or  defensive 
tactical  operations  as  part  of  a  company  or  combined  arms  team.  Platoons  are 
required  to  conduct  fire  distribution  planning  and  control  as  they  execute  their 
tactical  missions.  The  focus  of  these  operations  is  on  training  platoon  gunnery 
tasks,  not  training  tactical  operations,  even  though  tactical  operations  are 
addressed  during  the  training.  During  the  conduct  of  these  operations,  individual 
vehicles  will  use  precision  advanced  gunnery  procedures  while  engaging  the  target 
array. 

Operations  will  be  divided  into  three  categories  starting  with  missions  requiring 
training  of  simple  tasks  and  progressing  in  difficulty  to  more  complex  tasks. 
Platoons  will  progress  through  each  of  the  three  categories:  Basic,  Intermediate, 
and  Advanced.  A  fourth  category.  Combat,  includes  missions  from  the  three 
primary  categories  that  will  be  conducted  using  free  movement  capabilities. 
Platoons  will  progress  through  these  categories  sequentially,  advancing  to  the  next 
category  once  the  platoon  has  successfully  demonstrated  proficiency  at  the  current 
level.  The  determination  of  proficiency  will  be  based  on  the  platoon  attaining  at 
least  a  qualified  score  on  all  the  missions  in  the  category.  The  four  operations 
categories  are  briefly  described  below. 
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These  missions  will  focus  on  training  individual  leader  tasks  and  collective  gunnery 
tasks  while  the  platoon  is  conducting  basic  platoon  tactical  tasks  under  daylight 
and  limited  visibility  conditions.  The  platoon  training  tasks  will  be  performed 
while  the  platoon  is  conducting  either  defensive  (e.g.,  defend  a  battle  position)  or 
offensive  operations  involving  only  Move  and  Assembly  Area  type  missions. 
Company  operations  orders  with  specified  and  implied  tasks  will  be  developed  for 
all  missions.  Platoon  vehicles  will  move  on  pre- determined  routes/paths,  with  the 
capability  to  adjust  speeds  or  start/stop  at  any  point.  Tanks  in  hide  positions  or 
turret  defilade  can  move  to  hull  defilade  (firing  position),  back  again,  and  to  an 
alternate  or  supplementary  position  as  required. 

5.2. 1.1. 2. 2  Intermediate 

These  missions  will  focus  on  training  platoon  collective  gunnery  tasks  while 
executing  defined  training  tasks  (e.g.,  hasty  defense  or  attack,  conduct  a  delay, 
disengage  from  the  enemy,  conduct  movement  to  contact,  attack  and  seize  an 
objective)  during  the  conduct  of  offensive  and  defensive  missions  under  daylight 
and  limited  visibility  conditions.  Company  operations  orders  with  specified  and 
implied  tasks,  along  with  fragmentary  orders  (FRAGO),  will  be  developed  for  the 
missions.  At  least  two  offensive  and  defensive  missions  will  have  a  FRAGO  issued 
to  the  platoon  that  will  require  it  to  switch  from  offense  to  defense  or  vice  versa. 
Missions  will  be  conducted  with  vehicle  movement  controlled  as  in  the  Basic 
category  missions. 

5.2.1. 1.2.3  Advanced 

As  in  the  intermediate  category,  these  missions  will  focus  on  training  platoon 
collective  gunnery  tasks  while  executing  defined  training  tasks  during  the  conduct 
of  offensive  and  defensive  missions  under  daylight  and  limited  visibility  conditions. 
Company  operations  orders  with  specified  and  implied  tasks,  along  with 
fragmentary  orders  (FRAGO),  will  be  developed  for  the  missions.  Each  offensive  or 
defensive  mission  will  have  two  or  more  FRAGOs,  with  the  first  one  issued  to  the 
platoon  as  it  completes  its  initial  mission  requirements,  and  the  second  issued  as 
the  platoon  completes  the  first  FRAGO.  All  missions  will  be  conducted  with  vehicle 
movement  controlled  as  in  the  Basic  and  Intermediate  category  missions. 

5.2.1. 1.2.4  Combat  (Free  Movement) 

As  previously  stated,  combat  includes  missions  from  the  three  primary  categories 
that  will  be  conducted  using  free  movement  capabilities.  Each  vehicle  commander 
verbally  directs  the  movement  of  his  vehicle.  These  vehicle  movement  directives 
will  be  executed  by  an  operator  at  the  lOS  using  a  joystick  controller  interfaced  to 
the  crewstation’s  host  computer.  This  joystick,  along  with  a  slide  controller  to 
increase/decrease  vehicle  speed,  will  control  the  movement  of  the  vehicle.  The 
operator  will  also  have  an  out-the-window  display  presenting  a  view  of  the 
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battlefield  as  would  be  seen  by  the  vehicle  driver,  and  will  use  the  lOS  IVIS  map- 
view  for  orientation  on  the  battlefield. 

The  addition  of  the  Combat  missions  will  increase  the  potential  for  disorientation 
and  confusion  on  the  battlefield,  thereby  increasing  the  platoon  leader’s 
responsibility  to  ensure  all  of  the  platoon  vehicles  maneuver  and  stay  together 
within  the  prescribed  company  scheme  of  maneuver.  Vehicle  commanders  will  be 
responsible  for  ensuring  their  vehicles  maneuver  in  the  correct  position  according  to 
the  defined  platoon  formation. 

5.2.1.2  CCTT  Training  System 

As  a  tactical  trainer  focusing  on  collective  armor  and  infantry  tasks,  CCTT  is 
capable  of  providing  training  to  individual  crew  and  unit  personnel  covering  the 
skills  and  knowledge  of  crew  through  company  task  force  level  doctrine  for  the 
execution  of  combat  missions.  As  previously  noted,  CCTT’s  strength  is  in  platoon 
and  company  tactics  and  doctrine  training,  extending  to  some  battalion-level  tasks. 
It  utilizes  a  variety  of  manned  simulators  in  conjunction  with  computer-generated 
semi-automated  forces  (SAPOR)  to  populate  the  battlefield  with  potentially  large 
numbers  of  enemy  and  friendly  forces  engaged  in  a  dynamic  free-play  combat 
environment.  This  ongoing  exercise  is  monitored  by  operators  manning  various 
workstations  (e.g.,  MCC/MC,  AAR,  SAPOR).  These  operators,  chiefly  the 
battlemaster  or  0/C,  supervise  and  direct  the  action  to  attempt  to  maximize  the 
desired  training  benefit. 

After-action  review  (AAR)  and  performance  assessment  consists  of  overall  summary 
statistics  including  killer-victim  scoreboard,  direct  and  indirect  fire  reports, 
ammunition  expenditure,  loss  and  force  exchange  ratios,  etc.  These  reports  can  be 
generated  and  displayed/printed  for  individual  module,  platoon,  or  company  levels. 

5.2. 1.3  AVCATT 

The  limited  data  available  on  AVCATT  training  system  requirements  precludes  a 
detailed  comparison  to  evaluate  how  it  fits  within  the  CCTT  and  ACTS  envelope. 
The  ORD  defines  AVCATT  as  a  system  “which  trains  and  sustains  individual,  crew, 
collective,  and  joint  task  force/combined  arms  skills”.  It  is  to  be  interoperable  with 
other  CATT  trainers  and  employ  common  components  such  as  SAP  and  AAR. 
AVCATT  is  to  support  individual  and  crew  level  training  for  newly  fielded  systems 
that  do  not  currently  have  dedicated  trainers,  such  as  the  RAH-66  Comanche,  as 
well  as  support  these  plus  existing  trainers  (e.g.,  AH-64A  Apache,  UH-60 
Blackhawk,  and  CH-47  Chinook)  in  collective  and  joint  task  force/combined  arms 
training  simulation.  AVCATT  is  required  to  provide  high  fidelity  weapons  flyout 
models  and  high  fidelity  visual  systems  to  support  the  capability  to  train  and 
sustain  critical  individual  and  crew  gunnery  skills  between  live  fire  qualifications. 
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5.2. 1,4  Summary 

AGTS  is  the  training  requirements  “high-driver”  for  GIOS,  primarily  in  terms  of 
data  requirements,  scoring  software,  and  Instructor  Operator  workload.  The 
scoring  and  data  requirements  impact  is  discussed  in  Section  5.2.2;  the  information 
display  and  system  control  requirements,  their  impact  on  operator  workload,  and 
ways  to  alleviate  the  workload  are  discussed  in  Sections  5.2.3,  6.2,  and  6.3.3. 

5.2.2  Scoring  Data  Requirements 

The  AGTS  system,  unlike  CCTT,  uses  computer-based  scoring  algorithms  to  assess 
student  performance  during  crew  training  exercises.  Students  are  given  three 
separate  scores  focusing  on  different  training  objectives:  one  score  for  Target 
Acquisition,  one  for  Reticle  Aim,  and  one  for  System  Management.  For  platoon 
training,  AGTS,  like  CCTT,  primarily  uses  subjective  instructor/company 
commander  surrogate  evaluation  of  tactical  proficiency  based  on  Tank  Platoon 
Mission  Training  Plan  Standards.  The  result  of  the  evaluation  is  a  GO  or  NO-GO 
(pass/fail)  decision  for  the  platoon.  However,  AGTS  also  provides  an  objective 
evaluation  of  platoon  gunnery  skills  based  on  the  percentage  of  targets  destroyed 
and  also  by  using  Tank  Table  XII  Gunnery  Standards.  CCTT  does  collect  and 
present  for  AAR  presentation  a  number  of  statistics  concerning,  among  other 
things,  module  and  platoon  performance,  including  killer-victim  scoreboard,  direct 
fire  reports,  ammunition  expenditure,  loss  exchange  ratios,  etc. 

The  following  sections  specify  the  AGTS  crew  training  scoring  criteria  from  which 
training  system  data  requirements  are  derived.  Specific  simulation  software 
variables  used  to  support  scoring  can  be  obtained  when  and  if  required.  This 
scoring  criteria  is  summarized  from  an  AGTS  Exercise  Detailed  Design  Document 
[ref  9] .  Platoon  training  information  was  obtained  from  two  LMIS  internal  platoon 
training  concept  documents  [ref  10, 11].  For  most  of  the  scoring  metrics  there  are 
alternate  grading  assignments  depending  on  whether  and  what  type  of 
malfunctions  are  in  effect  for  the  exercise.  These  are  not  included  in  the  summary 
since  they  impact  only  scoring,  not  data  requirements,  other  than  noting  that  the 
malfunction  is  in  effect. 

In  addition  to  the  crew  and  platoon  training  programs  summarized  in  Section 
5.2. 1.1,  there  are  several  individual  skills  special  purpose  exercises  that  support 
individual  skills  training.  The  special  purpose  exercises  include: 

a.  Acquisition/Manipulation 

b.  Boresight/zero/screening  test 

c.  CITV  handover 

d.  Killer  tank 

e.  Evasive  helicopter 

f.  Long  range  gunnery 

g.  IVIS  message  generation 

h.  OIP  (Optical  Improvement  Package)  gunnery 

i.  COAX  machine  gun 
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These  exercises  are  either  instructor-based  or  use  existing  crew  scoring  algorithms 
for  performance  evaluation  so  they  do  not  add  additional  data  requirements. 

Following  the  crew  training  criteria  specification  is  a  tabular  summary  of  the 
categories  of  scoring  used  to  assess  the  training  objectives  previously  identified  in 
the  Training  Simulator  Requirements  Comparison  matrix  (Table  5.2.1-1). 

5.2.2. 1  Crew  Training  Performance  Scoring  and  Data  Requirements 

5.2.2. 1.1  Target  Acquisition  Scoring 

Target  Acquisition  Scoring  is  based  on  two  primary  metrics:  acquisition  time  and 
errors.  Special  scoring  for  CITV  Target  Handover  exercises  measures  designate 
time  instead  of  acquisition  time. 

I.  Acquisition  Time.  This  is  defined  differently  for  offensive  and  defensive 

mission  scenarios: 

A.  Defensive:  Acquisition  time  is  the  time  from  ownvehicle  in  defilade 
and  targets  fully  exposed  (target  activation  +  3.5  seconds)  to  the  time 
the  ownvehicle  reaches  an  enfilade  position. 

B.  Offensive:  Acquisition  is  measured  from  the  time  the  first  target  is 
fully  exposed  to  the  time  when  at  least  one  round  or  burst  is  fired  at 
each  target  in  the  situation.  Score  recorded  is  this  time  divided  by  2. 

For  Acquisition/Manipulation  exercises,  end  time  is  at  the  activation  of 
the  assigned  trigger  for  the  exercise. 

II.  Classification  and  Identification  is  defined  by  firing  errors: 

A.  Round  fired  at  a  non-target,  where  a  non-target  is  defined  by  the 
reticle  aim  point  being  greater  than  20  mils  from  the  center  of  mass  of 
a  point  target  or  greater  than  100  mils  from  the  center  of  mass  of  an 
area  target. 

B.  No  round  fired  at  a  target  during  exposure  (target  activation  to 
deactivation). 

C.  Round  fired  at  a  friendly  (i.e.,  reticle  aim  point  is  within  20  mils  of  the 
center  of  mass  of  a  friendly  when  round  is  fired). 

D.  Target  fired  upon  is  not  the  highest  valued  threat  of  the  targets  active 
in  the  situation.  Threat  value  is  derived  fi"om  a  look-up  table  (LUT) 
and  is  based  on  target  type,  range,  orientation,  and  target  motion. 

E.  For  Acquisition/Manipulation  exercises,  identification  errors  are  as 
defined  in  a)  and  b)  above  except  measure  is  taken  at  trigger 
activation,  not  round  firing 

III.  Designate  Time  for  CITV  Target  Handover  Exercises  begins  at  full  target 

exposure  (target  activation  +  3.5  seconds)  and  ends  at  activation  of  the  CITV 

designate  switch. 
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A.  Single  targets:  end  time  at  first  switch  activation 

B.  Multiple  targets:  end  time  at  last  switch  activation 

C.  Classification/Identification  errors  for  CITV  are  the  same  as  above 
except  measured  at  switch  activation. 

5. 2, 2. 1.2  Reticle  Aim  Scoring 

Calculation  of  kill  is  critical  to  reticle  aim  scoring  and  is  determined  by  ideal  aim 
point,  target  type,  and  ammunition  fired.  The  ideal  aim  point  is  dependent  on  the 
sight  in  use,  target  motion,  and  the  fire  control  mode  switch  position.  A  LUT 
defines  the  ideal  aim  point  for  a  specific  exercise  situation.  Target  damage  is 
assessed  by  computing  the  trajectory  of  the  ammunition  fired  based  on  the  reticle 
aim  point  at  the  time  of  firing  (and  any  other  influencing  factors  such  as  tube  bend, 
boresight,  etc.).  Each  target  has  a  defined  catastrophic  (K-Kill)  hit  plate  and  a 
mobility  hit  plate  (loss  of  mobility  but  the  target  is  still  potentially  lethal).  Point 
targets  are  killed  based  on  the  ammunition  type  and  the  number  of  rounds 
impacting  the  target  K-Kill  plate.  A  single  main  gun  round  of  appropriate 
ammunition  for  the  target  must  impact  within  the  K-Kill  plate  to  score  as  a  point 
target  kill.  A  LUT  defines  kill  capability  of  ammo  for  specific  targets.  Success 
against  area  targets,  such  as  troops  in  a  10  man  squad  or  RPG  team,  is  assessed  by 
percent  coverage,  defined  by  the  number  of  troops  killed  (a  troop  is  killed  when 
struck  by  one  or  more  rounds  of  COAX  ammunition).  If  the  number  of  COAX 
rounds  fired  at  one  area  or  point  target  is  greater  than  100,  the  reticle  aiming 
evaluation  is  lowered  one  letter  grade. 

Reticle  Aim  Scoring  is  based  on  six  primary  metrics:  time  of  first  round  or  burst, 
time  to  kill,  reticle  aim  error,  time  to  trigger  activation  for 

Acquisition/Manipulation  exercises,  reticle  aim  at  trigger  pull  error,  and  tracking 
accuracy. 

I.  Time  of  First  Round  or  Burst.  This  is  defined  differently  for  offensive  and 
defensive  mission  scenarios: 

A.  Defensive:  The  time  is  measured  from  ownvehicle  in  enfilade  and 
initial  target  in  situation  is  active  to  the  first  round  or  burst  fired. 

B.  Offensive:  If  stabilization  is  operational,  then  time  is  measured  from 
the  first  target  fully  exposed  (3.5  seconds  after  activation)  to  the  first 
round  or  burst  firing.  With  announced  stabilization  failures,  an 
additional  five  seconds  is  allowed  for  each  grading  level. 

II.  Time  to  Kill 

A.  Defensive:  Time  from  when  one  or  more  targets  are  active  and 
ownvehicle  reaches  the  enfilade  position  to  target  killed  or  deactivated. 

B.  Offensive:  Time  from  first  target  fully  exposed  (3.5  seconds  after 
activation)  to  all  targets  in  the  situation  killed  or  deactivated. 

C.  Friendly  targets:  For  any  situation  in  which  a  friendly  target  occurs 
and  no  round  is  fired  within  20  mils  of  that  target,  the  Time  to  Kill 


gioscdrl.doc 


18 


ADST-II-CDRL-029R-9600263 
September  13,  1996 


grade  for  that  target  is  set  to  “B”. 

III.  Reticle  Aim  Error  is  calculated  only  for  main  gun  rounds  and  is  based  on 

1)  the  outcome  of  rounds  fired  (first  and  second  rounds  are  scored  differently), 
where  firing  outcomes  are:  K-Kill,  M-Hit,  or  miss,  2)  type  of  ammunition,  and 
3)  reticle  aim  status.  For  MPAT  Air  Mode,  reticle  aim  error  is  based  on 
distance  in  mils  of  round  impact  from  target  center  of  mass.  For  any 
situation  in  which  a  round  is  fired  within  20  mils  of  or  impacts  a  friendly 
target  in  either  M-Hit  or  K-Kill  hit  plates,  the  reticle  aim  error  score  is  set  to 
an  “F”. 

IV.  Time  to  Trigger  Activation  for  Acquisition/Manipulation  Exercises 

A.  Defensive:  Time  from  initial  target  in  situation  is  active  and 
ownvehicle  is  in  enfilade  position  to  time  trigger  specified  for  exercise 
is  activated. 

B.  Offensive:  Time  from  first  target  fully  exposed  (3.5  seconds  after 
activation)  to  time  trigger  specified  for  exercise  is  activated. 

V.  Reticle  Aim  at  Trigger  Pull  Eiror  is  calculated  at  the  first  activation  of  the 
trigger  specified  for  the  situation  and  is  the  total  distance  (azimuth  and 
elevation)  between  the  reticle  ideal  aimpoint  and  the  centroid  of  the  target. 
Score  is  based  on  the  projected  impact  of  the  round  within  the  K-Kill  plate, 
M-Hit  plate,  or  outside  both  plates. 

VI.  Tracking  Accuracy  is  calculated  from  trigger  activation  to  3.5  seconds  before 
target  deactivation  and  reflects  the  percentage  of  time  that  the  total  distance 
between  the  ideal  aimpoint  and  the  reticle  location  is  within  the  K-kill  plate 
area  (based  on  the  projected  impact  of  the  round). 

5.2. 2. 1.3  System  Management  Scoring 

System  Management  grades  are  based  on  three  criteria:  pre-firing  errors,  time-of- 
fire  errors,  and  procedure  errors. 

I.  Pre-Fire  error:  Switch  check  is  performed  to  determine  if  lasing  occurs  prior 
to  firing  each  main  gun  round. 

II.  Time  of  Firing  Errors:  Switch  check  is  performed  when  weapons  fired  or  at 
designated  trigger  pull  in  Acquisition/Manipulation  exercises  to  determine 
ammunition  and  reticle  switch  status. 

A.  Ammunition:  For  second  and  subsequent  rounds  fired,  an  error  is 
logged  if  the  ammo  selected  is  not  appropriate  for  the  target. 
Appropriate  ammo  is  defined  in  a  LUT  specifying  ammo  type,  target 
type,  target  range,  and  target  aspect. 

B.  Reticles:  Error  defined  for  following  switch  states  at  time  of  fire: 
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1.  GPS/GPSE  is  in  use  and  at  low  power 

2.  Ammo  selector  does  not  match  the  ammo  fired 

3.  The  GAS  is  in  use  and  the  reticle  doesn’t  match  the  ammo  fired 

4.  The  gunner’s  thermal  sight  is  in  use  and  an  OIP  cue  is  active 

III.  Procedure  Errors: 

A.  Muzzle  Reference  Sensor  (MRS)  Update  error  -  one  MRS  update  error 
occurs  for  each  situation  in  which  the  number  of  main  gun  rounds  fired 
since  last  MRS  update  is  greater  than  six 

B.  Defilade  error  :  1)  Ownvehicle  returns  to  defilade  before  all  targets 
are 

killed  and  there  has  been  no  enemy  projectile  near- 
miss 

2)  Ownvehicle  fails  to  start  to  return  to  defilade 
position  within  10  seconds  of  an  enemy  projectile 
near-miss. 

C.  Ownvehicle  hit 

D.  NBC  Mode  Backup  error  -  Commander  fails  to  activate  NBC  mode 
backup  within  15  seconds  of  warning  message  “NBC  FILTER 
CLOGGED”  appearing  on  the  IVIS  display. 

IV.  Two  errors  are  defined  for  special  purpose  CITV  target  handover  exercises 
and  are  categorized  as  CITV  Target  Handover  Pre-Fire  Errors: 

A.  Stadia  Rangefinder  error:  The  commander,  using  the  stadia  reticle, 
fails  to  determine  the  range  to  the  target(s)  within  the  time  allowed  to 
an  accuracy  of  at  least  200  meters 

B.  Target  Designation  error:  The  commander,  within  the  time  allowed, 
fails  to  designate  the  target(s)  with  an  accuracy  of  no  more  than  3 
degrees. 

5.2.2.2  Scoring  Applied  to  Crew  Training  Tasks 

The  following  table  illustrates  how  these  three  major  scoring  criteria  are  applied  to 
the  previously  defined  crew  level  training  tasks  on  AGTS  (see  Table  5. 2. 2.2-1). 
Automated  crew-level  scoring  is  either  not  applicable  or  undefined  for  other 
training  systems  evaluated.  The  table  also  indicates  that  for  AGTS,  like  CCTT, 
platoon  tactical  performance  is  subjectively  evaluated  by  the  instructor  (company 
commander  surrogate)  and  graded  on  a  GO/NO-GO  basis.  AGTS  also  provides 
automated  gunnery  scoring  in  the  form  of  percent  targets  destroyed,  i.e.,  number  of 
K-Kills  logged  during  the  exercise  divided  by  the  total  number  of  targets  presented. 
Mobility  hits  are  not  counted,  and  fratricide  results  in  a  five  percent  gunnery  score 
penalty. 

Table  5. 2. 2.2-1  AGTS  Scoring  Applied  to  ARTEP  Training  Tasks 


TRAINING  TASKS 


SCORING 
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TRAINING  TASKS 

SCORING 

CREW  LEVEL  TRAINING 

ARTEP  Training  Missions: 

MANEUVER/TACTICS 

Target  Acquisition,  Reticle  Aim, 
System  Management 

JOINT  COLLECTIVE  TASK 
DEFENSE/OFFENSE 
SCENARIOS 

Target  Acquisition,  Reticle  Aim, 
System  Management 

FIRE  SUPPORT 

10  Subjective  GO/NO-GO 

MOBILITY/COUNTERMOBILITY/ 

SURVIVABILITY 

Target  Acquisition,  System 
Management  (Procedure  Errors  ii 
and  iii) 

CREW  COORDINATION 

Target  Acquisition,  System 
Management  (e.g.,  b(i),  c(ii)) 

PRECISION  GUNNERY 

Target  Acquisition,  Reticle  Aim, 
System  Management 

PLATOON/SECTION  LEVEL 

TRAINING 

10  Subjective  GO/NO-GO  for  Tactics; 
Percent  targets  destroyed  for 
gunnery  skills 

5.2.2.3  Follow-On  Data  Definition  Efforts 

An  effort  similar  to  this  GIOS  data  definition  was  previously  undertaken  by  Loral 
during  ADST  I.  They  conducted  an  evaluation  of  the  capabilities  of  DIS  standards 
and  protocols  to  support  precision  gunnery.  The  basis  for  their  evaluation  was  a 
comparison  of  tasks  and  data  used  by  the  MlAl  U-COFT  against  the  requirements 
existing  for  DIS  2.04  standards  and  protocols  at  the  time  of  the  study.  Their  results 
[ref  20]  indicate  that  DIS  2.04  can  support  precision  gunnery  for  about  98%  of  the 
required  functions.  Any  follow-on  GIOS  efforts  to  completely  specify  training  data 
requirements  for  AGTS  and  CCTT  will  use  this  initial  report  as  the  foundation 
upon  which  further  efforts  will  be  built.  In  addition  to  simply  identifying  data 
content,  as  this  report  did,  other  issues  such  as  data  update  frequency,  criticality, 
and  numerical  precision  would  also  have  to  be  evaluated. 

5.2.3  GIOS  System  Requirements 

This  section  summarizes  the  GIOS  system  requirements  identified  using  the 
previously  identified  AGTS,  CCTT,  AVCATT,  and  other  (e.g.,  AC-130U)  source 
documents.  One  additional  reference  document,  the  AGTS  System  Specification  [ref 
22],  also  served  as  a  significant  resource.  It  was  originally  intended  during  the 
course  of  the  GIOS  data  collection  effort  to  identify  training  system  requirements 
for  systems  other  than  the  three  primary  systems  (AGTS,  CCTT,  AVCATT)  that 
would  reinforce  or  possibly  extend  the  requirements  identified  for  these  systems. 
However,  the  only  additional  system  requirements  identified  of  any  significance 
were  for  the  Aviation  Reconfigurable  Manned  Simulator  (ARMS)  system  [ref  21]. 
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The  requirements  identified  for  this  system  are  included  in  the  following  summary 
matrix  (Table  5.2.3. 1-1). 

In  order  to  be  compliant  with  the  training  systems’  original  specifications,  the 
identified  requirements  must  also  be  met  by  the  GIOS  unless  specific  relief  can  be 
justified  and  is  granted.  Section  5.2.3. 1  identifies  these  explicit  existing  system 
requirements  for  AGTS,  CCTT,  AVCATT,  and  ARMS.  Section  5.2.3.2  identifies 
requirements  that  GIOS  must  meet  that  are  implied  by  or  derived  from  desired  or 
required  GlOS-unique  capabilities. 

5.2.3. 1  Legacy  System  Requirements 

Table  5.2.3. 1-1  summarizes  the  requirements  that  must  be  accommodated  at  some 
level  by  GIOS  if  it  is  to  be  compatible  with  the  listed  systems.  AGTS  has  all  real¬ 
time  simulation  monitoring  and  control  functions  allocated  to  the  lOS.  CCTT, 
AVCATT,  and  ARMS  have  distributed  these  real-time  functions  to  different 
workstations  including  an  lOS,  an  AAR  (real-time),  and  an  MCC/MC.  The  following 
table  identifies  how  the  training  system  requirements  defined  primarily  for  the 
AGTS  lOS  have  been  allocated  by  the  other  training  systems,  with  the  default  X 
cell  entry  noting  an  allocation  to  the  lOS.  However,  other  training  system  unique 
requirements  not  found  in  AGTS  have  been  included  to  the  extent  that  they  have 
been  identified. 
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Table  5.2.3. 1-1  Legacy  System  Instructor  Operator  Subsystem  Requirements 


Requirement 


General 

DIS  Compliant 

Information  Displays 

Video  Disolavs 

Crewstation  Display  Repeaters,  (e.g.: 

UVBs,  GAS,  GPS,  GPSE,  CITV,  IVIS) 

Driver's  Display 

Dismounted  Infantry  Display 

stealth  Visual  Display 

Plan  View  Display  (Topo) 

Data  Disnlavs 

Student  Performance  Metrics 

Student  Records 

Exercise  Descriptions/Op  Ords 

Exercise  Control  Parameters 

System  Performance  Status 

Entity/Module  Status 

Compass  Heading 

Aural  Disnlavs 

Communications  (Crew  I/C,  Platoon, 
Company,  10  net) 

Hardcopy  Printouts 

Crew  Performance  Summary 

Control  Inputs 

Traininer  System  Control 

Initialization 

Daily  Readiness 

Configuration 

Student  Record  Management 

Termination 

Traininer  Scenario  Control 

Scenario  Selection/Initiation 

Exercise  Real-Time  Intervention 

Re-initialization 

Reconstitution 


Pause/Resume  (see  Freeze/Unfreeze) 

Missing  Crewmember  Simulation _ 

Loader 


Source 


X  (Goal) 

_ AAR 

X  (Goal) 

(Platoon) _ AAR 

(Goal) 


X _ AAR _ 

X _ 

X  MCC/MC  ? _ 

X  MCC/MC  MCC _ 

X  MCC/MC  MCC  MCC 


X  MCC/MC  X/(MCC)  MCC 

X  MCC/MC 


MCC/MC _ 

MCC/MC _ X 

MCC/MC 


Driver  (Discrete) 

X 

Driver  (Continuous  (Free  movement)) 

X 

Environmental  Effects 

X 

MCC/MC 

X 

X 

Digital  Message  Control 

X 

Note  2 
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Source 


Requirement 

ACTS 

CCTT 

AVCATTi 

ARMSi 

Malfunctions 

Note  3 

Note  2 

Tactical  Support 

Smoke 

X 

Note  2 

X 

Artillery/Indirect  Fire 

X 

Note  2 

Flare  Illumination 

X 

Note  2 

Reconnaissance 

X 

Instructional  Control 

Video  Source  Select  for  Monitoring 

X 

AAR 

FreezeAJnfreeze 

X 

MCC/MC 

X 

X 

Replay  Control 

X 

X 

X 

Communication  Network  Select 

X 

MCC/AAR 

Network  Voice  Communications 

X 

MCC/AAR 

Entity  Status  Select 

X4 

MCC/AAR 

Instructional  Data  Display  Select 

X 

AAR 

Digital  Voice  Note-taking 

X 

AAR 

Event  Marking 

X3 

X 

X 

Plan  View  Display  Control 

X3 

AAR 

AAR 

AAR 

Stealth  View  Control 

X4 

AAR 

AAR 

AAR 

Target  Activation/Control 

X 

SAFOR 

SAFOR 

Print  Crew  Performance  Summary 

X 

X 

Processes 

Scoring  of  Crew  Performance  Data 

X 

Read  and  use  PDU  data  for  image  generation, 
scoring,  audio,  etc. 

X 

X 

X 

PDU  generation  of  lO  control  inputs 

X 

X 

X 

Information  generation  (text  and  non-imagery 
graphics) 

X 

X 

X 

Data  recording  for  instant  replay 

X 

Target  generation  (Scripted  for  crew;  SAFOR 
for  platoon 

Scripted 

SAFOR 

SAFOR 

lOS/Trainer  Ratio 

Crew 

1:1 

Section 

1:1 

1:2  or  3 

Platoon 

1:1 

1:4 

Other 

ARMS  1:6  at 
Co.  level 

MCC  Control  of  Independent  Exercises 

_ 

Up  to  5 

Indiv.  & 
collective 

Notes:  (1)  AVCATT  and  ARMS  requirements  specify  an  lOS,  AAR  (real-time),  and  MCC.  An  X 
signifies  an  lOS  requirement;  AAR  and  MCC  requirements  are  explicitly  noted. 

(2)  The  system  has  capabilities  for  these  effects  but  no  operator  control 
requirement  has  been  identified. 

(3)  Capability  currently  is  either  not  funded  or  not  required. 

(4)  Capability  exists  in  the  PAAR  but  is  not  currently  utilized  for  ACTS. 


gioscdrl.doc 


24 


ADST-II-CDRL-029R-9600263 
September  13,  1996 


5.2.3.2  Implied  or  Derived  GIOS  Requirements 

The  requirements  defined  in  the  previous  section  are  those  that  can  be  traced  back 
to  specific  requirements  documents.  Obviously,  the  instantiation  of  common 
requirements  across  systems  may  be  different  for  each,  driven  by  differences  in 
hardware  and/or  software  architectures,  secondary  design  goals  or  requirements, 
etc.  For  GIOS,  several  derived  requirements  have  been  identified.  These  are 
driven  by  various  factors  such  as  the  requirement  to  be  a  stand-alone  DIS 
workstation,  the  desire  to  reduce  10  manpower  by  providing  automation 
enhancements  over  existing  systems,  the  necessity  of  being  reconfigurable  to  meet 
several  different  systems’  demands,  and  the  desire  to  minimize  hardware 
requirements.  These  GIOS  derived  requirements  are  discussed  below. 

The  AGTS  implementation  of  most  of  its  lOS  requirements  is  through  direct 
interconnections  between  computational  and  visual  display  subsystems,  e.g.,  video 
distribution  amplifiers,  local  ethernet,  direct  PIE  (programmable  interface 
electronics)  connection,  RS-232,  etc.  The  implementation  of  these  requirements  for 
a  portable  (across  systems),  stand-alone,  DIS  compliant  GIOS  workstation  implies  a 
new  solution.  Some  implications  of  this  include  the  following: 

•  GIOS  will  require  an  image  generator. 

AGTS  fulfilled  the  requirement  for  lOS  monitoring  of  crewstation  sights  and  in- 
vehicle  video  displays  by  providing  analog  repeaters  of  the  video  generated  for 
the  crewstations.  GIOS  will  require  an  image  generator  to  regenerate  selected 
in-vehicle  displays  from  PDU-based  data. 

•  The  GIOS  image  generator  will  require  at  least  two  channels. 

The  number  of  monitors  used  to  display  crewstation  video  at  the  AGTS  lOS  is 
fixed  per  vehicle  t3rpe  but  varies  between  vehicles.  For  the  M1A2,  for  example, 
up  to  seven  separate  display  monitors  are  part  of  the  lOS  for  platoon  training. 
The  number  of  displays  available  at  GIOS  will  be  fixed  based  on  the  ntunber  of 
channels  available  from  its  IG.  Based  on  user  feedback  obtained  during  AGTS 
data  collection,  the  IG  needs  a  minimum  of  two  channels  to  support 
simultaneous  display  of  the  commander’s  and  gunner’s  views. 

•  Access  to  other  crewstation  video  by  the  lO  at  the  GIOS  must  be  quick  and  easy  if 
manpower  reductions  proposed  are  to  be  realized. 

The  AGTS  solution  for  the  requirement  to  provide  the  capability  for  the  10  to 
view  any  in-vehicle  display  is  to  provide  a  dedicated  monitor  to  repeat  each 
display  channel  in  the  crewstation.  Thus,  the  10  visually  samples  the  desired 
information  from  the  spatially  distributed  array  of  information  displays.  If  one 
10  was  to  conduct  platoon  training,  up  to  22  displays  would  need  to  be  monitored 
in  the  current  AGTS  implementation  (7  displays  per  vehicle  x  4  vehicles  =  28, 
minus  3  each  duplicate  PVDs  and  situation  monitors).  As  indicated  above,  GIOS 
potentially  will  provide  two  display  channels  simultaneously.  Thus,  GIOS  must 
provide  the  10  with  easy  and  quick  access  to  other  displays.  A  means  for 
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“intelligent”  dynamic  display  switching  based  on  a  real-time  assessment  of  the 
situation  (e.g.,  individual  vehicle  crew  performance),  on  10  demand  by  voice  or 
other  selection  means,  or  customized  by  each  10  will  be  investigated.  The 
number  of  actual  video  display  monitors  required  at  the  GIOS  depends  on 
several  factors  including  niunber  of  simultaneous  displays  required,  video 
windowing  capabilities  of  workstations,  display  resolution  requirements,  etc. 

•  Natural  language  processing  (NLP)  is  required  in  order  to  eliminate  10 

driver ! loader  simulation  tasks  and  the  need  for  a  role  player  at  each  lOS  during 
platoon  free  movement  scenarios. 

Currently,  ACTS  simulates  loader  and  driver  functions  through  manual  “Wizard 
of  Oz”  simulation  by  the  10.  To  support  10  workload  reduction  in  the  effort  to 
reduce  10  manpower  requirements  for  platoon  training,  this  function  can  be 
allocated  to  a  voice  recognition  system.  This  could  easily  handle  the  loader 
functions  and  discrete  driver  tasks  (“Driver  move  up”,  “Driver  move  back”,  etc.), 
and  could  work  in  conjunction  with  route  planning  and  terrain  following 
algorithms  to  support  free  movement  exercises  currently  planned  for  platoon 
training.  The  goal  would  be  to  locate  NLP  hardware  and  software  at  the  GIOS 
to  make  it  simulator  independent  and  to  potentially  support  its  use  by  the  lO  as 
a  control  device.  Also,  separate  voice  recognition  systems  may  be  required  for 
each  crew  “channel”  to  handle  multiple  requests  during  platoon  exercises. 

However,  an  NLP  system  may  need  to  reside  on  the  host  processor  at  each 
crewstation  if  voice  quality  issues  warrant.  This  is  largely  an  empirical 
question. 

•  The  plan-view  display  (PVD)  must  be  generated  by  the  GIOS  workstation. 

The  AGTS  implementation  of  the  PVD  is  still  being  worked.  However,  we 
believe  a  PVD  can  effectively  serve  as  a  primary  resource  for  monitoring  the 
ongoing  exercise  and  extracting  additional  information  desired  or  required  by 
the  10.  AGTS  presents  all  exercise  and  system  status  information  as  text  on  a 
dedicated  “situation  monitor”  display.  Any  PVD  presentation  will  be  on  a 
physically  separate  display.  Given  the  limitations  of  GIOS  display  real  estate 
and  the  desired  approach  of  intelligently  integrating  information,  it  is  believed 
that  this  situation  monitor  and  PVD  information  can  be  combined,  with  much  of 
the  situation  monitor  information  displayed  graphically  on  the  PVD  either 
continuously  or  on-demand  as  required. 

•  GIOS  must  contain  a  PDU  data  logging  capability. 

AGTS  has  a  requirement  for  “instant  replay”,  which  is  a  limited  duration  but 
total  capability  visual  scene  and  event  replay  function.  AGTS  meets  this 
requirement  by  keeping  a  ‘sliding  window’  of  event  and  database  information  in 
the  host  computer’s  memory.  A  stand-alone  GIOS  will  need  to  store  PDUs  in 
order  to  re-create  the  desired  temporal  window  of  events  and  imagery. 
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•  Embed  all  10  functionality  possible  into  the  DIS  compliant  GIOS;  provide  a 
common  core  of  software  and  hardware. 

To  minimize  the  impact  to  existing  systems  and  to  make  the  system  as  “generic” 
or  extensible  as  possible,  GIOS  must  be  as  self-contained  and  capable  as 
practicable.  This  core  capability  should  encompass  the  majority  of  requirements 
identified  for  the  key  systems  to  date,  but  must  be  designed  in  a  modular  fashion 
so  capabilities  can  be  easily  added  as  required  for  future  systems.  Maintaining 
DIS  compliance  is  one  way  to  help  ensure  this  compatibility. 

5.2.3.3  Summary 

The  requirements  identified  for  the  core  systems  of  AGTS,  CCTT,  and  AVCATT 
should  serve  as  the  basis  for  development  of  the  GIOS  and  verification  of  its 
completeness.  It  is  believed  that  how  well  the  derived  requirements  are  met  will 
largely  determine  the  suitability  or  utility  of  GIOS  in  an  operational  setting. 

Design  options  or  considerations  for  meeting  these  requirements  are  discussed  in 
the  following  section,  along  with  a  proposed  design  concept  strawman. 

6.  System  Design 

A  preliminary  design  approach  has  been  developed  for  the  Generic  10 S.  A  common 
hardware  suite  with  software  and  data  tailored  to  the  application  is  proposed. 
Software  portability  has  been  stressed  so  that  the  lOS  may  be  used  on  different 
platforms.  COTS  and  GOTS  components  have  been  used  to  the  maximum  extent 
practicable. 

Traditional  lOS  designs  containing  multiple  hardwired  displays  were  reviewed  and 
contrasted  to  software  controlled,  workstation  based  windowing  schemes.  Scoring 
reqmrements  for  the  various  domains  were  consolidated  into  a  unifying  training 
matrix  framework.  Potential  DIS  protocol  extensions  were  identified,  along  with  an 
assessment  of  network  loading  induced  by  the  new  data  types.  Implications  of  the 
HLA  on  the  design  of  the  Generic  lOS  were  considered.  This  was  done  by 
leveraging  work  that  is  underway  on  Lockheed  Martin  Internal  Research  and 
Development  (IR&D)  projects. 

In  the  development  of  this  preliminary  design  we  have  leveraged  existing  assets, 
such  as  the  AGTS  lOS  and  Exercise  Manager  to  the  extent  practicable.  We  are  also 
taking  advantage  of  the  ADA-based  real-time  simulation  software  architecture 
developed  by  Lockheed  Martin  under  IR&D  funding. 

We  have  investigated  new  technologies  such  as  natural  language  processing  (NLP) 
in  order  to  reduce  instructor  and/or  operator  task  loading.  New  low  cost  image 
generators  were  reviewed  to  assess  feasibility  of  utilizing  these  devices  to  render 
imagery  on  demand,  as  opposed  to  hardwired  video  repeaters.  We  have  also  looked 
into  relevant  intelligent  tutoring  work. 
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The  GIOS  design  must  be  evolutionary  so  that  it  verifiably  continues  to  meet  the 
requirements  and  user  expectations  of  the  legacy  AGTS  and  GATT  systems. 
However,  it  must  also  be  revolutionary  to  the  extent  necessary  to  achieve 
reconfigiirability,  display  consolidation,  and  I/O  workload  reduction  goals  that  have 
not  been  achieved  in  any  lOS  fielded  to  date.  We  also  believe  it  is  this  latter 
challenge  that  will  ultimately  determine  the  operational  effectiveness  and  user 
acceptance  of  the  GIOS. 

In  developing  the  design  considerations  discussed  in  the  following  sections,  we 
referred  back  to  user  interviews  and  on-site  observations  conducted  during  the 
AGTS  lOS  data  collection  effort  described  in  Section  5.1.  In  addition,  a  brief 
literature  review  was  conducted  to  identify  design  issues  and  recommendations 
relevant  to  the  GIOS  effort.  We  have  undertaken  our  GIOS  concept  definition  with 
a  user-centered  design  approach,  integrating  available  technologies  with  advanced 
man-machine  interface  design  concepts.  There  are  many  general  human-computer 
interface  (HCI)  design  references  that  are  relevant  to  the  GIOS  design  effort  [e.g., 
refs  31,  32,  33],  and  there  exist  standards  for  physically  integrating  the  human  into 
a  video  display  terminal  (VDT)  workstation  environment  [ref  34] .  However,  the 
references  discussed  in  the  following  sections  are  generally  restricted  to  those  that 
deal  specifically  with  lOS  design  issues. 

6.2  Design  Considerations 

The  three  areas  of  the  GIOS  design  that  we  consider  key  for  an  operationally 
successful  system  are:  (1)  automating  operator  and  role-player  functions  currently 
assigned  to  the  I/O,  (2)  reducing  workload  so  that  potential  manpower  savings  can 
be  realized,  and  (3)  identifying  cost-effective  solutions  to  the  GIOS  display 
generation  requirement.  Of  course,  the  automation  of  functions  will  be  undertaken 
as  part  of  an  overall  integrated  design  solution,  not  simply  as  piecemeal 
replacement  of  I/O  functions.  These  three  areas  form  the  core  of  subsequent  design 
consideration  discussions  and  the  strawman  concept  description. 

Successfully  meeting  the  goals  defined  in  (1)  and  (2)  will  ensure  that  GIOS  supports 
the  primary  mission  of  any  training  simulator:  to  successfully  train  personnel  on 
the  tasks  defined  for  that  simulator.  Item  (3)  above  will  determine  to  a  large  extent 
whether  GIOS  is  an  economically  viable  solution  to  the  requirements  identified  in 
this  FAS. 

6.2.1  Automated  Functions 

In  an  article  discussing  training  device  design  in  general  and  10 S  design  issues 
specifically,  an  Army  psychologist  [Ref.  35]  states  that  the  “real  difficulty  in 
designing  a  quality  lOS  comes  when  the  instructor  and  operator  duties  are 
combined.  Tremendous  workload  stress  is  placed  upon  instructors  who  must  handle 
both  chores”  (page  52).  The  article  goes  on  to  list  tasks  that  should  be  performed  by 
an  instructor.  These  include  tasks  such  as  simulation  and  exercise  initialization. 
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simulation  control  and  trainee  performance  monitoring,  evaluation  of  crew 
proficiency  and  diagnosis  of  performance  problems,  crew  debrief,  data  files 
management,  etc.  The  list  does  not  contain  any  of  the  operator  or  role  player  duties 
identified  as  an  AGTS  lOS  requirement.  We  concur  that  the  GIOS  user  should  not 
be  required  to  carry  out  tasks  that  have  no  instructional  value. 

Users  at  Forts  Knox  and  Hood  also  voiced  similar  sentiments  [ref  7,  8].  They  stated 
the  desire  that  either  crew  positions  be  added  for  the  driver  and  loader  or  that  these 
functions  be  automated  so  that  the  instructor  could  concentrate  on  monitoring  crew 
performance  and  providing  feedback  and  critique.  It  has  been  previously  discussed 
(Section  5.2.3.2)  that  these  AGTS  operator/role  player  functions  could  be 
automated.  This  would  relieve  the  instructor  of  these  tasks  and  allow  him  to  focus 
on  instructional  tasks  in  crew  mode,  and  to  potentially  reduce  manpower 
requirements  for  platoon  training.  The  methods  for  automating  these  functions  are 
discussed  in  Sections  6.2. 1.1  and  6.2. 1.2. 

In  addition  to  off-loading  the  loader  and  driver  simulation  functions  from  the 
instructor,  it  is  anticipated  that  further  instructor  aiding  will  be  required  to  achieve 
manpower  reductions  for  platoon  training.  The  rationale  and  concepts  for 
implementation  of  this  aiding  are  presented  in  Section  6.2. 1.3. 

6.2. 1. 1  Automated  Loader  Functions 

Automating  or  simulating  the  loader  for  a  vehicle  crew  would  be  a  relatively 
straightforward  application  of  voice  recognition  (VR)  and  natural  language 
processing  (NLP)  technologies.  Current  speaker  independent  VR  systems  are 
achieving  the  robustness  that  is  required  for  applications  such  as  this.  Using  a 
speaker  independent  system  eliminates  the  need  for  lengthy  and  tedious  training  by 
the  students.  NLP  requirements  for  this  application  would  be  relatively  minor, 
since  the  vocabulary  of  TC  commands  to  the  loader  is  small  and  the  synteix 
relatively  well  defined  (i.e.,  ‘LOAD’  command  and/or  ammo  type,  e.g.,  SABOT,  Heat, 
MPAT,  etc.).  Voice  generation  representing  the  loader’s  response  (UP!)  is  already  in 
place  on  AGTS.  There  are  potential  issues  regarding  the  VR  operation  in  a  noisy 
environment  and  under  stressful  training  situations  that  would  need  to  be  assessed 
and  resolved  if  necessary. 

The  NLP  and  VR  system  would  be  integrated  into  the  tank  commander’s  (TC)  voice 
intercom,  either  at  the  source  or  as  reconstituted  from  PDUs  at  the  GIOS.  Voice 
quality  and  recognizer  keying  issues  will  determine  where  the  system  is  integrated. 
The  VR  would  activate  on  a  defined  cue.  For  example,  the  system  could  ‘watch’  for 
the  ke3rword  “Load”  or  an  ammo  t5q)e  to  trigger  its  recognition/response  processes. 

It  would  then  interpret  the  command  and  send  out  the  appropriate  discrete  signal 
that  is  currently  generated  in  response  to  the  instructor’s  key  press. 

6.2. 1.2  Automated  Driver  Functions 

Simulating  the  driver  in  AGTS  would  essentially  be  the  same  as  described  above  for 
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the  loader  for  those  driver  tasks  that  are  relatively  discrete,  such  as  moving  up/back 
to  enfilade/defilade,  moving  to  an  alternate  position,  and  all  other  tasks  currently 
accomplished  via  a  keypad  entry  at  the  lOS.  Again,  the  VE  system  could  key  on  a 
specific  word  such  as  “Driver”  and  issue  the  same  discrete  as  is  output  by  the 
current  dedicated  key  at  the  lOS.  The  VE/NLP  system  would  have  to  be  integrated 
such  that  it  would  accept  input  from  either  the  TC  or  the  gunner,  since  either  can 
issue  commands  to  the  driver. 

Complications  to  driver  function  automation  arise  from  those  platoon  training 
exercises  that  involve  free  movement.  The  proposed  ACTS  solution  is  for  the  driver 
role  player  to  use  a  joystick  to  maneuver  the  vehicle  over  the  terrain  in  response  to 
TC  (or  in  limited  instances  gunner)  commands.  While  the  VE/NLP  system  is 
capable  of  capturing  and  responding  to  these  commands,  the  continuous  vehicle 
control  over  terrain  and  around  obstacles  will  require  additional  automation.  This 
type  of  terrain  reasoning  and  terrain  following/obstacle  avoidance  route  generation 
capability  exists  (e.g.,  for  ModSAF)  and  could  be  extended  to  this  application. 
According  to  the  current  ACTS  free  maneuver  concept,  the  endpoint  for  this  route 
planning  will  always  be  available  as  an  IVIS  checkpoint  that  has  been  designated 
as  a  waypoint.  Subsequent  checkpoints  and  all  objectives,  battle  positions,  or  other 
locations  to  which  the  platoon  will  maneuver  will  have  checkpoint  designations. 
Final  vehicle  maneuvering  into  defilade  position  may  require  “snapping”  into  a 
predefined  location,  since  this  is  a  precise  maneuvering  task.  Having  a  vehicle  fall 
behind  or  wander  off  course  in  order  to  pose  a  training  challenge  to  the  platoon 
leader  could  be  handled  in  a  manner  analogous  to  system  malfunctions  or  could  be 
instructor  initiated. 

6.2. 1.3  Automated  Instructor  Aiding 

Once  the  instructor  has  been  relieved  of  operator/role  player  responsibilities,  his 
workload  during  crew  training  should  be  acceptable.  This  conclusion  is  based  on 
previous  AGTS  analysis.  In  fact,  even  with  existing  COFT  loader  and  driver 
simulation  tasks,  some  lOs  reported  that  training  sessions  can  sometimes  be 
boring.  They  wanted  to  leave  operator/role  player  functions  assigned  to  them  so 
that  they  could  have  more  to  do  to  help  Tseep  their  heads  in  the  game’. 

However,  when  attempting  to  aggregate  training  tasks  responsibilities  and  allocate 
to  one  instructor  during  platoon  training,  workload  issues  emerge  as  a  predominant 
concern.  Even  if  10  crew  training  workload  is  acceptable,  multipl3dng  this  by  four 
and  adding  additional  platoon-unique  task  requirements  clearly  poses  a  workload 
issue.  This  is  an  intuitive  assessment  that  is  consistent  with  research  in  this  area. 
For  example,  a  recent  study  assessed  the  impact  of  having  a  single  operator  monitor 
and  control  more  than  one  device  [ref  36] .  While  the  context  was  that  of  an 
industrial  security  task  and  not  an  lOS  for  a  training  simulator,  the  basic  structure 
of  the  tasks  is  similar  enough  to  warrant  comparison. 

In  the  study,  there  were  three  major  tasks  that  each  operator  had  to  perform:  1) 
monitor  one  or  more  (up  to  three)  displays  for  the  presence  of  an  intruder  (basic 
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monitoring  task  analogous  to  monitoring  crew  repeater  displays),  2)  determine  the 
orientation  and  perspective  of  each  active  sensor  (which  could  be  fixed  or  mobile) 
and  develop  a  single  spatial  model  of  the  depicted  information  (similar  to 
determining  the  orientation  of  vehicles  in  a  platoon  through  viewing  their  repeater 
displays),  and  3)  integrate  the  information  from  multiple  displays  to  construct  a 
single  model  of  the  environment  and  its  situation  (information  the  PVD  aids  in 
conveying  at  an  lOS).  The  operator  response  for  the  study  was  to  indicate  the 
number  of  intruders  detected  and  their  locations  within  the  building  containing  the 
simulated  camera  sensors. 

The  general  result  of  interest  was  that  increasing  the  number  of  displays, 
particularly  for  mobile  sensors,  significantly  increased  operator  workload  (inferred, 
not  measured)  and  degraded  performance,  i.e.,  the  time  it  took  the  operator  to 
perform  the  tasks.  While  preliminary,  the  results  of  this  study  are  consistent  with 
the  body  of  human  factors  literature  regarding  human  performance  under  multiple 
task  demands,  and  is  also  consistent  with  our  intuitions  regarding  assigning 
multiple  crew  performance  monitoring  demands  to  a  single  10.  Of  course,  any 
GIOS  design  actually  implemented,  either  as  a  prototype  or  dynamic  mock-up, 
would  be  evaluated  to  assess  instructor  workload. 

The  implication  is  that  for  a  single  10  to  be  able  to  achieve  effective  platoon-level 
instructional  capability,  some  assistance  must  be  provided  to  him  to  reduce  his 
monitoring  load.  These  observations  are  supported  by  user  comments,  some  of 
which  are  reproduced  here  fi’om  previously  referenced  AGTS  documents.  The 
following  ai ding-related  comments  are  from  lOs  at  Forts  Knox  and  Hood: 

•  Have  a  menu  (pick  list)  of  probable  crew  errors  pop-up  on  the  screen  when  an 
error  or  a  number  of  same-type  errors  are  identified  by  the  computer  scoring. 
Allow  the  instruction  to  select  error  type  and  enter  as  a  marker. 

•  Provide  help  menus  on  the  situation  monitor 

•  The  computer  should  provide  a  summary  of  crewman  deficiencies  and 
recommend  corrective  exercises 

•  The  system  should  be  designed  so  that  manpower  resource  requirements  for 
platoon  training  do  not  exceed  one  instructor  and  one  operator. 

Given  all  of  this,  we  believe  the  case  is  well  made  for  instructor  operator  aiding, 
primarily  during  platoon  training. 

Since  the  instructor  will  most  probably  be  able  to  view  the  vehicle  sight  repeater 
displays  for  only  one  crewstation  at  a  time,  and  his  primary  focus  of  attention  will 
generally  be  on  the  PVD,  a  significant  10  aid  would  be  a  crew  performance 
monitoring  function.  This  function  could  use  existing  crew  scoring  algorithms  to 
monitor  individual  crew  gunnery  performance  during  platoon  exercises.  It  is  a 
stated  assumption  by  most  platoon  training  programs  that  crews  will  be  proficient 
at  using  their  vehicle’s  weapons  systems  to  engage  targets  prior  to  participating  in 
platoon-level  training.  Assuming  this  to  be  true,  it  is  envisioned  that  a  crew  having 
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performance  problems  in  these  areas  will  be  the  exception  rather  than  the  rule.  If 
so,  instructor  monitoring  of  individual  crew  performance  during  platoon  exercises 
would  be  unnecessary  and  uninformative  for  the  majority  of  crews  for  the  majority 
of  the  time.  Only  when  a  crew  is  having  some  trouble  would  the  instructor  need  to 
be  alerted  to  direct  his  attention  to  a  particular  crew.  In  addition  to  performing  this 
display-by-exception  monitoring/alerting  function,  this  performance  monitoring  aid 
could  also  provide  a  crew  performance  score  in  addition  to  the  overall  platoon 
gunnery  summary  at  the  end  of  a  training  session. 

The  next  progression  beyond  a  crew  performance  monitoring/alerting  function 
would  be  some  form  of  intelligent  tutoring  system.  This  is  a  more  radical  extension 
of  the  scoring  algorithm  baseline  that  would  not  only  monitor  crew  performance, 
but  would  diagnose  problems  and  propose  remedial  actions  or  exercises.  This  crew 
feedback  could  be  accomplished  through  the  use  of  text  messages  on  existing 
crewstation  displays  or  through  speech  synthesis  over  the  intercom.  The  benefit  to 
the  instructor  would  be  the  elimination  of  crew-level  performance  monitoring  and 
troubleshooting  for  even  those  crews  encountering  problems  in  basic  gunnery  skills. 
The  instructor  could  focus  his  attention  on  the  platoon’s  overall  performance. 

Adding  this  capability  represents  a  significant  effort  that  is  beyond  the  proposed 
near-term  follow-on  activities. 


6.2.2  Information  Presentation  Alternatives 


The  original  MlAl  COFT  trainer  lOS  has  two  video  monitors,  one  for  the 
commander’s  view  and  one  for  the  gunner’s,  plus  a  situation  monitor.  PGT  adds  a 
topographic  map  or  planview  display.  As  the  vehicles  that  the  trainers  simulate 
have  added  more  displays  in  the  crewstation,  such  as  in  the  M1A2,  the  solution  to 
the  lOS  monitoring  problem  has  been  to  simply  add  more  repeater  displays.  As 
previously  noted,  the  AGTS  M1A2  platoon  lOS  has  up  to  six  displays  in  addition  to 
the  situation  monitor.  See  Figure  6.2. 2-1. 
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Figure  6.2.2-1:  Existing  AGTS  lOS  Design  Approach 

This  solution  minimizes  the  software  impact  to  the  lOS  but  pays  the  penalty  of 
additional  hardware  costs.  Also,  as  discussed  above  in  Section  6.2.1,  asking  a  single 
instructor  or  operator  to  monitor  multiple  displays  can  present  performance  and 
workload  problems.  The  alternative  is  to  limit  the  number  of  physical  displays  to 
perhaps  two  or  three  and  provide  the  capability  for  I/O  or  software  controlled 
switching  among  display  options.  The  information  content  and  format  of  these 
displays  should  also  be  optimized  to  convey  the  information  the  instructor  needs  to 
perform  his  job  in  a  timely  and  efficient  manner. 

Even  with  the  limited  number  of  displays  used  at  the  lOS  in  COFT  and  PGT,  user 
interviews  indicated  the  desire  to  have  different  display  options  or  information 
presentation  alternatives.  Again  returning  to  some  of  the  relevant  AGTS  lOS  study 
findings,  lOs  at  Ft.  Knox  and  Ft.  Hood  provided  the  following  comments  concerning 
information  presentation  at  the  lOS: 

•  The  COFT  lOs  look  at  the  gunner’s  view  and  the  situation  monitor  almost 
exclusively.  They  secondarily  refer  to  the  commander’s  view.  They  were  not 
opposed  to  an  idea  presented  to  them  about  having  the  commander’s  view 
appear  as  a  lower  resolution  insert  into  another  display,  i.e.,  using  a  picture-in- 
picture  approach. 

•  PGT  lOs  also  used  the  PVD  display  a  great  deal,  in  addition  the  gunner’s  view 
and  situation  monitor. 

•  The  lOs  would  like  to  be  cued  on  the  PVD  where  targets  will  come  up  when  they 
are  activated.  They  would  like  to  see  the  PVD  better  utilized  to  present 
additional  information,  and  would  like  coordination  of  information  displayed  on 
the  PVD  and  situation  monitor. 

•  They  would  like  a  graphic  means  of  displaying  tracking  errors. 

•  They  would  like  to  see  information  that  is  currently  displayed  on  separate  pages 
of  a  display  (e.g.,  situation  monitor  and  performance  analysis  data)  integrated 
into  a  single  display  page. 

•  They  would  like  real-time  access  to  performance  analysis  data  (COFT). 

Other  sources  identified  during  the  literature  review  also  have  stressed  the 
importance  of  the  methods  of  information  presentation  at  an  lOS.  Madden  and 
Englert  [ref  37]  performed  a  literature  review  and  conducted  a  survey  of  instructor 
operators  to  assess  the  utility  of  a  number  of  lOS  instructional  features.  They 
assessed  the  amount  each  feature  was  used,  its  ease  of  use,  the  training  value  of  the 
feature,  and  the  amount  of  training  the  I/Os  received  in  the  use  of  the  feature.  The 
report  discusses  the  survey  data  and  the  desirable  and  undesirable  aspects  of  lOS 
designs  and  instructional  features.  Some  of  the  pertinent  items  discussed  in  the 
report  include  the  following: 
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•  “The  most  common  problems  identified  by  instructors  involved  information 
presentation  (e.g.,  number  of  hierarchical  (sic)  levels  in  the  software,  number  of 
pages  containing  related  information).  The  user-computer  interface  was 
mentioned  frequently  as  a  source  of  errors  and  frustration.”  (page  7) 

•  “Instructors  who  used  graphical  repeater  displays  commented  favorably  on  the 
capability  to  select  a  section  of  cockpit  instruments  to  be  viewed  rather  than 
having  all  instruments  continuously  displayed.”  (pages  37-38) 

•  A  computer  mouse,  touchscreens,  and  dedicated  function  keys  were  preferred 
input  devices.  At  the  time,  voice  recognition  technology  was  not  in  use  at  any 
lOS,  although  the  report  discusses  this  as  a  potentially  viable  input  approach. 

A  conclusion  of  the  report  is  that  “Efficient  training  console  design  can  be 
accomplished,  but  only  if  display  and  control  designs  are  based  on  information  and 
action  requirements  . . .”  (page  17).  We  have  tried  to  follow  this  approach  in 
defining  the  GIOS  requirements  in  Section  5.2.3.  This  was  the  approach  followed  in 
the  AGTS  lOS  requirements  definition  study  and  will  continue  to  be  the  process 
followed  in  any  further  GIOS  design  efforts. 

One  of  the  10  comments  cited  above  was  a  desire  for  more  graphical  depiction  of 
information.  This  was  discussed  in  the  article  cited  above,  and  was  further  explored 
in  a  paper  presented  at  NAECON  by  Meyn  [ref  38].  The  central  tenet  of  the  paper 
is  Slimmed  up  by  the  following  quote:  “One  way  to  reduce  instructor’s  workload  and 
increase  effectiveness  is  to  optimize  the  use  of  graphics  at  the  lOS.  When  this 
occurs,  raw  data  is  no  longer  presented  to  the  instructor,  but  rather  useful 
extractions  of  relevant  information  is  provided”  (page  1035).  The  paper  goes  on  to 
discuss  the  use  of  color,  highlighting,  windowing,  icons,  and  various  input  devices. 

The  key  concept  put  forward  in  this  paper  with  which  we  concur  is  that  of 
presenting  the  instructor  with  information  rather  than  data.  Again,  it  is  relatively 
easy  from  a  design  and  software  implementation  perspective  to  simply  present  the 
instructor  with  lists  of  simulation  variables  and  performance  data  from  which  he 
can  extract  and  synthesize  the  information  he  needs  to  assess  student  performance, 
diagnose  problems,  and  provide  feedback.  It  is  more  difficult  and  time  consuming  to 
perform  the  human  factors  analysis  to  define  instructor  tasks,  determine 
information  and  control  requirements,  and  assess  the  best  methods  for  presenting 
this  information  and  implementing  control  methods.  But,  as  we  have  seen  through 
user  comments  and  the  references  above,  the  outcome  of  this  process  will  be  a  better 
product  and  in  some  cases  may  determine  the  difference  between  a  successful  and 
unsuccessful  one. 

Much  of  the  foundation  analyses  that  would  be  directly  applicable  to  GIOS  have 
already  been  conducted  for  AGTS.  Also,  a  first  step  towards  re-designing  the 
COFT-type  lOS  interface  from  text-based  to  GUI-based  displays  was  undertaken  as 
a  final  project  for  an  advanced  engineering  course  [ref  24]  conducted  under  the 
auspices  of  MMIS  (now  LMIS).  The  project  looked  at  alternate  GUI  standards 
(OpenLook  versus  Motif),  developed  a  protot3q)e  window  environment  for  the  lOS, 
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and  briefly  examined  issues  relating  to  redesign  of  specific  display  screens,  such  as 
the  situation  monitor  and  performance  analysis  screen.  The  project  also  developed 
a  preliminary  hardware  and  software  interface  design.  While  not  directly 
applicable  to  the  GIOS  architecture,  some  of  the  issues  explored  would  still  be 
relevant  to  the  GIOS  design  effort. 

To  summarize,  the  primary  displays  as  defined  by  the  users  seem  to  be  the  gunner’s 
and,  to  a  lesser  extent,  commander’s  displays,  the  situation  monitor,  and  the  PVD. 
Their  desire  to  integrate  more  information  onto  the  PVD  and  have  it  correlated  with 
other  displays  is  reflected  in  our  initial  GIOS  design  concept  (Section  6.3). 
Integration  of  this  information  should  be  primarily  graphical  in  format  to  realize 
the  potential  benefits  described  above  and  to  maintain  consistency  with  the 
information  already  displayed  on  a  PVD.  The  data  presented  to  the  instructor 
should  be  pre-processed  as  necessary  to  meet  his  task  requirements,  i.e.,  should  be 
compiled  into  information,  not  merely  displayed  as  data. 

The  current  assumption  is  that  GIOS  will  not  be  able  to  display  all  potentially 
useful  or  necessary  information  at  one  time.  Thus,  the  instructor  must  be  able  to 
access  this  “hidden”  information  easily  and  in  a  timely  manner  to  support  his  task 
at  hand.  Control/display  options  to  achieve  this  include  pop-up  windows,  fixed,  pop¬ 
up,  or  ‘soft  switch’  menus,  voice  generation,  or  full-display  page  switching  in 
response  to  operator  selections  via  traditional  mouse,  keypad,  or  touch-screen 
selections.  Voice,  through  the  use  of  VR  and  NLP,  could  serve  as  a  means  to 
alleviate  potential  problems  encountered  with  menuing  structures  (navigating 
menu  depth,  breadth,  etc.)  required  to  provided  all  necessary  functionality  with 
limited  control  and  display  resources.  NLP  processing  could  offer  a  single-layered 
command  structure  where  any  function  or  operation  could  be  accessed  via  a  one-  or 
two-word  command.  Obvious  integration  issues  include  directing  10  comments  to 
the  VR  system  versus  to  crew  members  and  assessing  the  impact  of  the  additional 
verbal  burden  on  existing  voice  communication  workloads. 

Alternately,  it  is  possible,  albeit  more  difficult,  to  provide  automatic,  dynamic 
information  display  reconfiguration.  An  expert  system-type  process  could  monitor 
ongoing  training  events  and  switch  or  present  information  to  the  instructor  based 
on  rules  developed  out  of  the  task-based  information  and  control  requirements 
analysis.  This  type  of  dynamic  display  configuration  based  on  an  assessment  of 
operator  intent  has  been  under  research  and  development  in  aviation  and  process 
control  environments  for  some  time.  We  are  not  aware  of  any  use  of  this  technique 
at  this  time  outside  of  the  R&D  arena. 

Finally,  the  strawman  GIOS  design  concept  defines  the  potential  display  real  estate 
as  a  virtual  display  space.  This  is  primarily  because  the  number,  size,  and 
technology  to  be  used  as  the  display  (and  possibly  control)  interface  has  yet  to  be 
determined.  The  goal  is  to  achieve  something  approaching  this  virtual  display 
space,  whether  using  large  CRT  or  flat  panel  displays  with  windows  or  using 
smaller,  independent  displays.  More  details  concerning  the  GIOS  strawman  design 
concept  are  presented  in  the  following  sections. 
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The  preceding  sections  have  discussed  design  considerations  that  primarily  impact 
GIOS  system  software,  although  some  issues  regarding  input/output  devices  have 
been  reviewed.  This  section  discusses  the  major  GIOS  hardware  component  -  the 
image  generator  (IG).  The  IG  will  largely  determine  the  effectiveness  of  GIOS  in 
presenting  the  necessary  gunner  display  view  with  the  resolution  and  image  detail 
required  for  the  instructor  to  monitor  performance  and  diagnose  problems.  The  IG 
selection  will  also  primarily  determine  the  cost  viability  of  the  GIOS  design,  in 
terms  of  recurring  hardware  expenses. 

As  previously  described,  AGTS  provides  the  instructor  with  the  required  crew  sight 
monitoring  capability  by  repeating  at  the  lOS  the  video  generated  for  the 
crewstation  sights  and  displays  by  an  SE  1000  IG.  This  is  a  viable  solution  because 
each  crewstation  has  a  dedicated  lOS.  However,  GIOS  must  be  a  stand-alone  DIS 
network  asset  that  requires  all  of  its  inputs  to  come  over  the  network  via  PDUs. 
Thus,  all  information  presented  to  the  instructor,  whether  voice,  video,  or  data, 
must  be  extracted  from  the  PDUs  and  reconstituted  into  the  required  format  at  the 
GIOS.  This  5delds  the  derived  GIOS  requirement  for  an  image  generator  as 
discussed  in  Section  5.2. 3. 2,  with  the  additional  derived  requirement  for  at  least 
two  channels  of  imagery.  In  addition,  the  IG  must  be  interoperable  with  both  CCTT 
and  AGTS  databases,  and  the  interface  needs  to  be  adaptable  to  the  GIOS  host 
software.  The  IG  needs  to  provide  a  reasonable  approximation  of  the  views  seen  by 
the  various  crews,  but  it  does  not  need  to  precisely  replicate  the  crewstation  display 
imagery  as  long  as  the  necessary  information  content  is  provided  to  the  GIOS 
instructor.  This  necessary  information  is  determined  by  the  analysis  of  the 
instructor’s  training  task  requirements. 

The  following  sections  establish  basic  IG  performance  requirements  and  identify 
candidate  IG  systems.  A  cost/performance  comparison  of  these  IGs  provides  the 
basis  for  establishing  a  ranking  of  the  systems  as  viable  solutions  to  the  GIOS 
stealth/IG  requirement. 

6.2.3. 1  Performance  Requirements 

Based  on  these  general  requirements,  specific  performance  requirements  can  be 
derived.  We  concentrate  on  the  two  parameters  that  typically  limit  IG  performance: 
polygon  rate  and  pixel  fill  rate. 

•  A  Polygon  Capacity  of 262,500  polygons  per  second  is  needed 

The  CCTT  requirement  is  to  process  3500  polygons  per  channel  at  15  Hz  update 
with  a  visibility  range  of  4  km.  To  support  precision  gunnery  and  aviation 
requirements,  longer  visibility  ranges  and  higher  update  rates  are  needed.  Using  5 
km  and  30  Hz  update  as  precision  gunnery  requirements  [ref  22] ,  and  assuming  the 
use  of  CCTT  databases,  we  get  3500*5/4*30*2  =  262,500  polygons  per  second. 
Aviation  requirements  could  easily  quadruple  this  figure,  if  we  assume  10  km 
visibility  and  60  Hz  update,  to  over  1  million  polygons  per  second. 
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•  A  Pixel  Fill  Rate  of  110  million  pixels  per  second  is  needed 

Assuming  two  channels  of  640  by  480  resolution,  and  a  depth  complexity  of  6  (i.e.,  6 
visits  to  every  pixel),  we  derive  the  textured  pixel  fill  rate  requirement  as 
640*480*2*6*30  =  110  million  pixels  per  second. 

6.2. 3.2  Alternatives 

The  primary  contenders  are  IG’s  manufactured  by  E&S,  Lockheed  Martin,  and  SGI. 
The  E&S  candidate  is  the  Liberty.  The  Lockheed  Martin  candidate  is  the  RealSD 
Pro,  and  the  SGI  candidate  is  the  Maximum  Impact.  We  picked  these  three 
candidates  for  the  following  reasons: 

•  Compatibility  with  CCTT  and/or  AGTS  databases  (Liberty,  RealSD  Pro) 

•  Existing  interface  with  proposed  host  software  (Maximum  Impact,  Real  3D  Pro) 

•  Low  cost,  high  performance  capabilities  (all  3  exhibit  Level  II  performance) 

The  three  contending  IG’s  were  compared  using  published  performance  data.  The 
1996  IMAGE  Society  Resource  Guide  and  IG  Survey  was  particularly  useful  [ref 
29].  Table  6. 2. 3-1  summarizes  the  results  of  this  comparison. 

Note  that  both  the  Real  3D  Pro  and  the  Maximum  Impact  exceed  the  polygon 
requirements  for  precision  gunnery,  and  approach  the  requirements  for  aviation. 
Therefore  we  focus  the  remaining  discussion  on  the  Real3D  Pro  and  the  Maximum 
Impact.  We  note  from  Table  6. 2. 3-1  that  the  Real  3D  Pro  exceeds  the  Maximum 
Impact  performance  with  respect  to  pixel  fill  rate  and  texture  capacity.  This  finding 
is  supported  by  the  third  party  performance  analysis  described  below. 


Table  6.2.3-1:  IG  Performance  Comparison 


Performance 

Liberty 

Real  3D  Pro 

Polygons/sec 

50Korl00Korl50K 

750K 

676K 

Textured  Pixels/Sec 

25  or  50  or  lOOM  (1) 

50  or  100  or  200M 

119M 

Texture  Memory 

1  or  2  or  4MB  (2) 

8  or  32MB 

1  or  4MB 

Video  Output 

640  by  480  to 

1024  X 1024 

640  by  480  to 

1024  X  768 

640  by  480  to 

1280  X 1024 

Video  Channels 

up  to  16 

lor  2 

up  to  4 

Occultation 

Hybrid 

Z  buffer 

Z  buffer 

(1)  “Span  full”  technique  increases  effective  capacity  by  2  or  more 

(2)  Assumes  16  bits  per  texel  (capacity  expressed  in  terms  of  number  of  texels) 


Gemini  Technology  Corporation  published  a  proposed  set  of  benchmarks  for  Image 
Generators  [ref  25].  These  benchmarks  are  normalized  to  the  SGI  RE2  in  a  typical 
single  pipe  configuration.  Gemini  developed  a  set  of  test  suites  stressing  polygon 
performance  and  pixel  fill  rates  in  realistic  situations;  i.e.,  fl5dng/driving  through 
real  3D  data  bases  via  predetermined  paths.  Preliminary  results  of  these  test  suites 
applied  to  a  number  of  low  cost  IG’s  were  recently  published  [ref  26] .  The  tests 
were  conducted  at  a  60  Hz  update  rate  with  double  buffering.  Double  buffering  is 
employed  by  all  real-time  IG’s  so  that  screen  updates  are  not  perceptible  to  the 
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observer.  The  following  devices  were  tested:  SGI  RES  (Infinite  Reality),  SGI  RE2 
(the  “control”  case),  LM  Real  3D  Pro  1100,  SGI  Maximum  Impact,  3DFX  Obsidian 
2200,  and  Intergraph  TDZ/GLZ5.  Results  for  the  ground  benchmark,  called  gvf 
re2stone,  are  shown  in  Table  6.2.3-2,  along  with  the  published  list  prices  (before 
discounts  are  applied).  Unfortunately  no  results  are  available  at  this  time  for  the 
E&S  Liberty. 


Table  6. 2. 3-2:  IG  Benchmark  Test  Results 


Image  Generator 

gvr  re2stone  results 

List  Price 

SGI  RE3  (1) 

1.74 

$205K 

LM  Real  3D  Pro  1100  (2) 

1.61 

$37K 

SGI  RE2  (3) 

1.00 

$135K 

SGI  Maximum  Impact 

1.00  (5) 

$54K 

(1)  SGI  Infinite  Reality  configured  with  one  raster  manager  and  two  RIOOOO  processors;  multi¬ 


channel  capability  built-in 

(2)  Entry  level  Real  3D  Pro  with  one  channel  at  640  by  480  output  and  50M  Pixels  per  second 
write  capacity 

(3)  SGI  RE2  configured  with  two  250Mhz  (R4400)  processors  and  a  graphics  pipe  with  2  raster 
managers;  single  channel  output 

(4)  SGI  Maximum  Impact  with  one  RIOOOO  processor;  single  channel  output 

(5)  Estimated  performance 

Note  that  the  Real  3D  Pro  out-performs  the  Maximum  Impact  by  a  significant 
margin  in  its  base  (minimal)  configuration.  For  GIGS  we  recommend  use  of  the 
Real  3D  Pro  Model  1400;  it  is  configured  with  two  640  by  480  NIL  channels 
(reconfigurable  as  one  1024  by  768  NIL  channel),  200  Mpixels  per  second,  30  or  60 
Hz  operation,  and  8MB  of  texture  memory.  List  price  is  $75K,  which  is  discounted 
by  35%  in  quantity  one  to  $49K. 

The  Real3D  Pro  can  utilize  existing  AGTS  databases.  Multi  Gen  databases  (the 
preferred  format),  and  can  import  CCTT  databases  in  SIF  format. 

6.3  Strawman  Concept 

The  strawman  design  concept  is  based  on  a  modular  software  architecture  and  a 
common  hardware  suite.  The  software  architecture  is  a  real-time,  reconfigurable 
design  composed  of  application  segments  built  on  a  core  services  layer.  This  is 
described  in  paragraph  6.3.1.  The  hardware  design  is  based  on  commercially 
available  components,  including  a  Unix  Workstation,  a  low  cost  Image  Generator,  a 
virtual  radio,  and  two  or  more  CRT’s  comprising  a  virtual  display.  The  hardware  is 
described  in  paragraph  6.3.2.  Paragraph  6.3.3  describes  the  design  concept  for 
Natural  Language  Processing. 

6.3.1  Software  Architecture 

The  software  architecture  proposed  for  the  GIGS  Strawman  design  is  based  on  the 
Ada  host  software  originally  developed  by  Lockheed  Martin  on  IR&D  funds,  and 
subsequently  augmented  by  various  government  programs  including  STRICGM’s 
Collective  Scene  Manager  project.  It  was  selected  because  of  its  availability  to  the 
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project  at  no  cost,  and  because  of  the  large  amount  of  existing  code  that  could  he 
used  “as  is”,  thereby  facilitating  a  rapid  prototyping  effort  with  minimal  software 
development. 

Note:  the  host  software  has  associated  with  it  limited  rights  in  accordance  with 
DFARS  252.227-7013.  This  gives  the  government  the  right  to  use,  duplicate,  or 
disclose  the  technical  data  (software)  with  the  express  limitation  that  disclosure 
outside  the  Government,  use  by  the  Government  for  manufacture,  or  in  the  case  of 
computer  software  documentation,  for  preparing  the  same  or  similar  software 
shall  not  he  made  without  the  written  permission  ofLMC. 

The  host  software  is  a  real-time,  modular  architecture  composed  of  segments  that 
plug  into  a  central  Core  Services  Layer  or  CSL  [ref  27].  Segments  are  groups  of 
objects  or  functions  closely  related  to  one  another  (e.g.,  weapons  functions). 

Segments  distribute  data  between  each  other  via  messages  on  a  virtual  network 
implemented  by  the  CSL. 

The  CSL  hides  the  message  transaction  process  from  the  segments.  It  supports 
multiple  CPUs  on  the  same  or  different  workstations  connected  on  a  network.  The 
CSL  utilizes  shared  memory  and/or  remote  core  services  for  message  passing.  A  key 
feature  of  the  CSL  is  its  ability  to  support  reconfiguration  of  segments  and  the 
virtual  network  at  run-time. 

Figure  6.3-1  illustrates  the  host  configuration  proposed  for  the  GIOS.  The 
segments  shown  shaded  are  existing  segments  that  are  available  for  use  in  GIOS 
(partial  shading  indicates  partial  implementation).  The  segments  are  written  in 
Ada,  C,  and/or  C++.  As  implied  by  the  diagram,  most  of  the  programming  effort 
will  go  into  development  of  the  Information  Manager  Segment  and  the  Language 
Parser  and  Dialogue  Controller  Segment. 
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Figure  6.3-1:  Software  Architecture 


6.3. 1.1  Segments 

Plan  View  Display:  The  Plan  View  Display  Segment  presents  an  overhead  or 
map  view  of  the  simulation  data  base  on  the  Virtual  Display.  The  view  is  created 
from  a  PVD  database  that  is  derived  from  the  3D  visual  database,  thus  assuring 
correlation.  This  PVD  presents  terrain,  cultural  features,  3D  features,  and 
battlefield  entities  in  user  selected  combination  on  the  display.  Battlefield  events 
such  as  weapons  firing  and  impact  are  also  shown.  The  operator  can  utilize  the  PVD 
to  select  entities  for  tethering  to  the  stealth  viewer  (i.e.,  the  IG).  The  PVD  will  be 
enhanced  with  additional  graphics  and  other  overlay  data  to  represent  information 
normally  provided  in  textual  form  on  the  situation  monitor. 

IG  Controller:  The  IG  Controller  segment  interfaces  the  host  software  with  the 
selected  Image  Generator.  It  currently  uses  an  ethernet  interface.  Versions  of  the 
IG  Controller  have  been  developed  for  the  CompuScene  SE  IG,  the  Real3D  Pro,  and 
another  version  is  being  developed  for  the  SGI  Maximum  Impact  on  the  Terrain 
Fidelity  DO.  This  segment  provides  system  synchronization  timing  via  the  regular 
ethernet  packets  received  from  the  IG.  30  Hz  and  60  Hz  update  rates  are 
supported. 

Speech  Recognizer/Synthesizer:  This  segment  consists  of  COTS  software;  it  is 
discussed  in  paragraph  6.3.3. 

Vehicle  Control:  This  segment  provides  a  mechanism  to  control  the  direction  and 
speed  of  the  ownship.  It  is  used  in  conjunction  with  terrain  following  (a  Mission 
Function)  so  that  the  vehicle  stays  properly  oriented  with  the  underlying  terrain. 
Since  a  major  objective  of  this  project  is  to  provide  an  automated  means  to 
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maneuver  the  ownship,  the  joystick  control  aspect  of  Vehicle  Control  will  be  used 
primarily  for  test  and  debug. 

This  segment  will  be  augmented  with  a  terrain  reasoning  module  that  will  be 
extracted  from  ModSAF  or  other  similar  source.  The  concept  for  free  maneuver,  as 
previously  described  in  paragraph  6.2. 1.2,  is  that  waypoints  will  be  known  ahead  of 
time;  therefore  the  terrain  reasoning  segment  simply  needs  to  find  an  obstacle-free 
path  from  point  A  to  point  B. 

DIS  Network  Interface:  This  segment  interfaces  the  host  software  with  the  DIS 
ethemet  network.  It  performs  the  functions  of  filtering,  coordinate  conversion,  time 
correction,  dead  reckoning  and  smoothing  [ref  30]. 

Gunnery  Controls:  A  Gunnery  Controls  segment  augmented  with  software  to 
emulate  the  actions  of  up  to  four  gunners  will  provide  the  mechanism  to  test  and 
evaluate  the  GIOS  in  crew  and  platoon  exercises.  This  segment  will  include  an 
emulation  of  the  weapon  effects  that  would  accompany  the  actions  of  the  gunners. 

Information  Manager:  This  segment  will  be  developed  to  provide  the  interface 
with  the  virtual  display  for  all  information  not  supported  by  the  PVD  segment. 

This  is  expected  to  include  both  visual  and  aural  forms  of  information.  This  segment 
is  also  responsible  for  managing  the  overall  information  presentation  from  all 
sources  -  the  IG  imagery,  the  PVD  and  overlays,  and  audio. 

Mission  Functions:  This  segment  performs  line  of  sight  tests,  collision  tests, 
weapon  impact  determinations,  and  terrain  following  calculations  in  real-time  in 
response  to  battlefield  events.  A  private  copy  of  the  visual  database  is  interrogated 
by  this  segment  to  perform  the  calculations.  This  approach  minimizes  the  transport 
delay  time  as  compared  to  the  IG  performing  these  calculations. 

Target  Processing:  The  Target  Processing  segment  controls  the  target  vehicles 
when  the  GIOS  is  operating  in  “scripted  target”  mode.  Scripted  targets  are  pre¬ 
programmed  to  follow  pre-specified  paths.  They  can  be  activated  and  deactivated  by 
the  lO,  and  they  will  stop  when  killed  by  a  weapon.  They  will  also  speed  up  and 
take  an  alternate  pre-programmed  path  when  fired  upon.  Note  that  this  segment 
will  be  disabled  when  a  SAPOR  is  used  to  control  intelligent  targets. 

Language  Parser  and  Dialogue  Controller:  The  software  comprising  this 
segment  is  discussed  in  paragraph  6.3.3. 

Exercise  Scoring:  This  segment  is  based  on  existing  AGTS  crew  training  scoring 
software  as  described  in  paragraph  5.2.2.  It  provides  a  post-exercise  performance 
grade  for  crew  training  exercises  and  will  serve  as  the  basis  for  the  real-time  crew 
performance  monitoring  instructor  aid  during  platoon  training  exercises. 

Training/Instructional  Control:  This  segment  is  based  on  existing  AGTS  crew 
training  software  that  performs  the  exercise  initialization  and  control  for  the 
training  programs  described  in  paragraph  5.2. 1.1.  It  serves  to  load  student  data 
files,  performs  exercise  selection  and  initialization,  and  provides  the  lOS 
functionality  for  real-time  exercise  monitoring  and  control. 
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Vehicle  Dynamics:  The  Vehicle  Dynamics  segment  provides  a  realistic  simulation 
of  the  dynamics  of  the  ownvehicle.  Since  the  initial  application  of  the  GIOS  will  be 
for  an  M1A2  CCTT  Quick  Start  module,  M1A2  dynamics  will  be  used.  This 
segment  includes  an  auto-pilot  function  which  will  be  used  in  conjunction  with  the 
terrain  reasoning  logic  added  to  the  Vehicle  Controls  segment  to  simulate 
automated  maneuver. 

Segment  Manager:  The  Segment  Manager  is  used  to  spawn  and  start  the  other 
segments.  Unlike  other  segments,  it  does  not  use  any  messages  to  communicate. 

The  Manager  Segment  reads  the  CSL  configuration  file  to  determine  how  to 
allocate  the  memory  area  for  the  messages  that  will  be  passed  between  the 
segments  (this  is  discussed  further  in  paragraph  6.3. 1.2).  It  is  also  responsible  for 
monitoring  timing  information,  calculating  CPU  loads  and  informing  segments  of 
the  allowable  run  time. 

6.3. 1.2  Core  Services  Layer 

The  Core  Services  Layer  provides  the  infi"astructure  to  interconnect  the  segments 
with  each  other  over  a  virtual  network.  As  mentioned  earlier,  the  CSL  supports 
multiple  CPUs  on  the  same  or  different  workstations  over  the  network.  The  CSL 
hides  the  message  transaction  process  from  the  segments.  The  CSL  utilizes  shared 
memory  and/or  remote  core  services  for  message  passing.  A  key  feature  of  the  CSL 
is  its  ability  to  support  reconfiguration  of  segments  and  the  virtual  network  at  run¬ 
time.  This  is  further  discussed  below. 

Configuration  Files:  Configuration  Files  define  the  segments  and  the  messages 
to  be  sent  between  the  segments.  However,  the  CSL  does  not  need  to  know  the  type 
of  data  stored  in  the  messages.  Message  information  required  includes  the  message 
name,  its  size,  a  buffer  factor  (the  number  of  instances  to  be  saved  at  one  time),  a 
protect  flag,  and  (X,Y)  position  of  the  message  on  the  display. 

Segments  are  stand  alone  executables.  The  CSL  needs  to  know  the  following  about 
each  segment  (via  the  configuration  file):  segment  name,  host  computer,  processor 
(which  CPU),  path,  priority,  locking  (to  prevent  swapping),  message  names  and 
associated  access  method  (read,  write,  or  read  and  write),  and  (X,Y)  position  of  the 
segment  on  the  display. 

Graphical  Configuration  File  Editor:  A  Motif  based  GUI  was  developed  to 
create  and  modify  configuration  files.  It  permits  visual  adding/deleting/modifying  of 
messages,  segments  and  connection  lines.  Host  computers  and  specific  CPUs  are 
graphically  identified.  This  is  a  powerful  tool  that  permits  new  configurations  to  be 
created  quickly  and  accurately,  typically  by  modifying  an  existing  configuration  file. 

6.3. 1.3  HLA  Extensions 

Under  IR&D  Lockheed  Martin  is  developing  an  approach  to  make  the  host  software 
compliant  to  emerging  HLA  standards.  This  work  is  being  led  by  UCF  professors 
Dr.  B.  E.  Petrasko  and  Dr.  R.  F.  Demara  under  subcontract  to  Lockheed  Martin. 
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Furthermore,  Lockheed  Martin,  UCF,  and  Veda  have  recently  teamed  to  respond  to 
the  recent  BAA  released  by  the  HLA  government  team  to  bring  more  contractors 
into  the  development  process. 

The  focus  of  the  HLA  IR&D  effort  has  been  on  development  of  an  Attribute  Object 
Model  (AOM)  as  the  key  component  required  to  integrate  the  CSL  of  the  host 
software  (an  examplar  Simulation  Object  Model  or  SOM)  with  the  HLA’s  Run  Time 
Infrastructure  or  RTI  (representing  the  Federation  Object  Model  or  FOM).  Thus, 
the  AOM  is  defined  in  terms  of  its  FOM/AOM  interface  and  its  SOM/AOM  interface. 
The  FOM/AOM  interface  provides  the  RTI  a  direct  means  of  reassigning  attributes 
of  a  SOM  whenever  necessary.  The  SOM/AOM  interface  allows  simulation 
suppliers  to  embed  attributes  in  Object  Request  Broker  (ORB)  or  legacy  simulations 
such  as  the  IRAD  host  software  for  enhancement  and/or  HLA  compliance. 

This  work  is  expected  to  continue  through  next  year  on  Lockheed  Martin  IR&D 
funds.  Results  will  be  available  for  use  by  the  OIOS  project. 

6.3.2  Hardware 

The  hardware  design  utilizes  commercially  available  components,  including  a  Unix 
Workstation,  a  low  cost  Image  Generator,  a  virtual  radio,  and  two  or  more  CRT’s 
comprising  a  virtual  display.  Figure  6. 3. 2-1  illustrates  the  design  concept. 

Unix  Workstation;  A  Sun  Ultra  2  Workstation  with  2  CPUs  and  Solaris  2.5.1  is 
recommended  to  host  the  Ada  real-time  host  software  described  in  6.3.1.  The 
proposed  host  software  was  developed  (and  continues  to  be  developed)  on  a  multi- 
CPU  Sun  Workstation,  so  this  approach  will  minimize  costs.  It  will  be  configured 
with  two  20  inch  color  monitors  in  a  dual-head  configuration. 

Low  Cost  IG:  Low  cost  IG  alternatives  were  discussed  in  paragraph  6.2.3.  In 
accordance  with  the  data  presented,  we  recommend  the  Real3D  Pro  Model  1400  as 
the  best  value  for  this  project.  In  addition,  it  has  already  been  interfaced  with  the 
host  software.  Two  color  multisync  monitors  will  be  included  to  provide  dedicated 
viewing  of  one  or  two  channels. 
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Figure  6.3. 2-1:  GIOS  Hardware  Design  Concept 

Virtual  Radio:  The  TSI  Virtual  Radio  is  the  tentative  selection,  given  its  low  cost 
and  availability.  Furthermore,  other  ADST  II  DO’s  are  using  this  radio  (CDF 
Upgrade,  Dismounted  Warrior  Network,  STP-21),  which  should  provide  some 
synergistic  benefit  to  GIOS. 

6.3.3  Natural  Language  Processing  (NLP) 

The  software  design  for  the  NLP  portion  of  the  host  software  is  shown  in  Figure 
6.3. 3-1.  It  is  modeled  after  work  done  by  Research  Triangle  Institute  for  a  National 
Guard  MlAl  Maintenance  Trainer.  It  is  briefly  described  below. 

Virtual  Environment 


Database  Customized  for  the  Application 


Figure  6. 3.3-1:  Natural  Language  Processing  Design 

Dialogue  Controller:  The  Dialogue  Controller  uses  goal-driven  processing  in  its 
interpretation  and  generation  of  utterances. 
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Virtual  Environment:  The  virtual  environment  is  a  three-dimensional  model  of 
the  interior  of  the  crew  station.  The  Dialogue  Controller  communicates  with  the 
Virtual  Environment  (VE)  in  order  to  change  the  state  of  the  world  based  on  user 
utterances.  The  Dialogue  Controller  must  also  monitor  the  user’s  interactions  in 
the  Virtual  Environment  to  keep  up  to  date  with  the  current  state  of  the  world. 

Speech  Synthesis:  The  lO  Assistant  communicates  with  the  user  by  modifying  the 
Virtual  Environment  (text  boxes,  arrows,  etc.)  and  also  by  speaking.  Current 
implementations  use  a  COTS  package  called  DECtalk  to  perform  text-to-speech 
synthesis. 

Speech  Recognition:  Users  can  communicate  with  the  10  Assistant  by  interacting 
with  the  Virtual  Environment  or  by  speaking.  The  current  PC  based 
implementation  uses  IBM’s  VoiceT3rpe  Application  Factory  for  speech-to-text 
conversion.  This  system  is  speaker  independent,  thus  the  computer  does  not  need 
to  be  trained  to  understand  each  individual  speaker.  This  recognizer  also 
recognizes  continuous  speech  where  words  do  not  have  to  be  separated  by  pauses. 

Thus  speakers  can  talk  in  their  natural  manner.  A  limitation  of  IBM  VoiceType  is 
its  limited  active  vocabulary.  To  combat  this  problem,  the  program  constantly 
changes  its  active  vocabulary  depending  on  the  current  dialogue  context.  This 
technique  greatly  increases  the  effective  vocabulary  size. 

Language  Parser:  A  Minimum  Distance  Translator  (MDT)  parser  is  utilized.  This 
parsing  technique  tries  to  match  the  spoken  words  to  the  closest  sentence  that  is 
acceptable  to  the  parser.  Thus  a  user  could  speak  an  utterance  that  is  out-of- 
grammar  and  be  understood.  The  Language  Parser  may  be  able  to  correctly 
interpret  the  utterance  if  it  is  close  to  something  in  the  grammar.  For  instance,  the 
user’s  utterance  “tank  working”  might  be  correctly  matched  with  “the  tank  is 
working”. 

Language  Grammar:  The  Language  Grammar  is  a  model  of  acceptable  spoken 
statements.  The  representation  language  is  quite  free;  literally  any  sentence  can  be 
encoded  in  the  grammar.  In  practice,  grammars  must  be  relatively  small  because  of 
the  speech  recognizer.  Thus  the  Dialogue  Controller  selects  which  grammars 
should  be  active  based  on  the  current  context.  This  increases  the  reliability  of  the 
speech  recognition  and  also  speeds  up  the  parsing  process. 

Static  Knowledge:  Static  Knowledge  related  to  operation  of  the  crew  station  is 
maintained. 

Dynamic  Knowledge:  New  knowledge  is  gained  during  an  interaction  with  a  user. 
Examples  are  procedural  errors,  what  steps  have  been  carried  out,  what  procedures 
did  the  trainee  have  problems  with,  and  so  on. 

Visual  Models:  In  order  to  appropriately  manipulate  and  interpret  the  Virtual 
Environment,  the  NLP  software  maintains  3D  models  of  the  environment.  The 
software  must  be  able  to  correctly  map  the  state  of  the  Virtual  crew  station  to 
appropriate  knowledge  in  its  database. 
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6.4  Integration  with  Legacy  Systems 
6.4.1  CCTT 

Addition  of  a  GIOS  to  a  CCTT  environment  would  require  changes  in  a  number  of 
areas.  These  changes  are  not  only  driven  by  the  incorporation  of  GIOS,  but  by  the 
requirements  of  simulation  for  precision  gunnery  training.  These  include  but  are 
not  necessarily  limited  to  the  following  items. 

Host  Software  Modifications:  the  CCTT  host  software  (i.e.,  the  M1A2  Manned 
Module  Simulator  CSCI)  will  require  modifications  to  extract  the  necessary 
information  from  the  associated  crew  station  and  from  the  appropriate  host 
modules.  In  particular,  all  gunner  and  commander  switch  settings  that  are 
controllable  by  the  soldier  in  the  crew  compartment  need  to  be  extracted  on  a 
regular  basis  and  prepared  for  transmission  to  the  GIOS  via  the  DIS  network. 

Since  the  Programmable  Interface  Electronics  (PIE)  used  on  CCTT  is  similar  to  the 
PIE  used  on  AGTS,  we  know  that  this  information  is  available  via  the  PIE  interface 
to  the  host  computer  at  a  regular  update  rate.  On  AGTS  all  of  the  crew 
compartment  data,  representing  approximately  300  bytes,  is  transmitted  to  the  host 
every  1/30  of  a  second. 

Additional  information  that  needs  to  be  extracted  from  one  or  more  of  the  host 
software  modules  is  gun  related  information,  such  as  the  number  of  times  the  gun 
has  been  fired  since  it  was  calibrated.  This  is  used  by  the  GIOS  scoring  algorithm 
to  compute  gun  droop.  Other  required  data  includes  line  of  sight  data  for  firing  and 
lasing,  exact  time  of  lase  and  fire,  and  turret  stabilization  status. 

Finally,  the  local  copy  of  the  NLP  software  will  need  to  be  integrated  with  the  host 
software,  along  with  terrain  reasoning  software  for  automated  maneuvering 
through  the  terrain  data  base. 

DIS  PDU  Modifications:  The  main  issue  with  PDU  modifications  is  the 
packaging  of  the  required  data  (described  above),  most  likely  in  a  Data  PDU,  and 
its  subsequent  transmission  to  the  GIOS  over  the  DIS  network.  We  do  not  believe 
this  poses  a  bandwidth  loading  concern,  since  PDUs  are  only  sent  when  there  is  a 
change  in  state.  We  estimate  that  once  per  second  is  more  than  sufficient,  on 
average;  with  4  crew  stations  in  a  platoon,  this  5delds  4  PDUs  per  second  additional 
load  on  the  network.  With  CCTT  sized  to  accommodate  851  entities  and  1285  PDUs 
per  second  [ref  12,  pages  3-11  &  12],  the  additional  network  load  imposed  by  this 
information  is  negligible. 

We  will  rely  on  the  PDU  translator  being  supplied  by  the  CDF  Upgrade  DO  to 
perform  the  necessary  conversions  between  DIS  2.0.4  r  (for  revised)  used  by  CCTT 
and  the  DIS  2.0.4  used  by  GIOS.  Figure  7.2-1  in  paragraph  7.2  illustrates. 

Event  Synchronization:  An  important  issue  in  precision  gunnery  is  accurate 
representation  of  position  and  time  by  all  participants  in  a  gunnery  exercise.  Prior 
to  AGTS,  gunnery  systems  utilized  dedicated  networks  with  s3mchronized  clocks, 
thus  permitting  all  entities  to  move  at  a  synchronous  30  Hz  update  rate.  AGTS  and 
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future  gunnery  training  systems  must  cope  with  asynchronous  networks  and  dead 
reckoning.  The  AGTS  approach  is  to  use  Network  Time  Protocol  (NTP)  to 
synchronize  all  clocks  in  the  network  to  a  reference  clock  combined  with  small  dead 
reckoning  thresholds  to  minimize  dead  reckoning  errors  [ref  301  •  The  impact  to 
CCTT  would  be  higher  PDU  rates  and  the  introduction  of  NTP  or  similar  scheme  to 
support  absolute  time  stamps.  The  higher  PDU  update  rates  should  not  be  an  issue 
since  gunnery  exercises  do  not  require  as  many  simultaneous  moving  models  as 
tactical  exercises  [ref  22].  Absolute  time  stamps  should  be  implementable  via 
software  changes  only. 

IG  Update  Rate  Change:  An  important  lesson  from  the  platoon  gunnery  training 
experience  in  Europe  is  the  need  for  30  hz  scene  update.  Unless  the  scene  is 
geometrically  recomputed  (not  just  refreshed)  at  a  minimum  of  30  Hz,  target 
acquisition  during  turret  slew,  shooting  on  the  move,  and  shooting  at  fast  moving 
targets  is  unrealistically  difficult  and  therefore  forces  incorrect  procedures  to  be 
learned  [ref  4]. 

The  CCTT  IG  was  specified  to  run  at  15  Hz,  which  was  deemed  adequate  for  the 
tactical  tasks  trained  on  CCTT.  Increasing  the  update  rate  to  30  Hz  should  be 
straightforward,  but  it  may  be  expensive  to  do  so  while  maintaining  the  same 
database  content.  Additional  polygon  processing  capability  would  be  required  to 
maintain  the  same  scene  detail  of  3500  polygons  per  channel  at  the  higher  update 
rate.  Alternately,  the  data  base  could  be  thinned  to  approximately  1750  polygons 
per  channel,  which  is  comparable  to  the  AGTS  polygon  load  per  channel  [ref  22]. 
Since  fewer  moving  models  are  required  for  a  gunnery  exercise  than  a  tactical 
exercise,  it  should  be  possible  to  accommodate  the  higher  update  rate  for  moving 
model  processing  in  the  IG  by  computing  fewer  model  positions  and  attitudes  at  the 
higher  rate.  Note  that  the  Multiple  Image  Suppression  overscan  feature  of  the 
CCTT  IG  would  not  solve  the  “smooth  track”  problem  for  moving  targets  (they 
would  still  update  their  position  at  a  15  Hz  rate). 

Database  Modifications:  The  CCTT  database  will  require  some  thinning  to 
support  the  higher  update  rate  required  for  gunnery  training,  as  mentioned  above. 
The  modified  database  will  then  be  converted  to  run  in  GIOS  native  formats.  This 
includes  visual,  plan  view  display,  and  exercise  database  formats.  Tools  to 
accomplish  these  conversions  should  be  available  to  the  ADST II  program  in  the 
near  future. 

Weapon  System  Simulation  Fidelity:  Recently  troops  from  Fort  Hood  received 
training  on  both  the  AGTS  and  the  CCTT  M1A2  simulators.  Discussions  with  these 
troops  were  held  after  they  had  completed  their  training  on  both  simulators  [ref  42] . 
One  of  the  major  concerns  they  expressed  regarding  CCTT  performance  was  the 
inaccurate  representation  of  force  feedback  in  the  gunner’s  handles,  as  well  as  an 
inaccurate  turret  response  transfer  function.  Since  both  the  AGTS  and  CCTT 
simulators  utilize  a  common  crew  station  developed  by  the  same  vendor,  it  should 
be  a  straightforward  matter  to  retrofit  the  force  feedback  upgrades  made  by  the 
AGTS  program  to  CCTT.  Further,  the  turret  transfer  function  should  be  a 
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relatively  minor  software  modification  to  the  CCTT  host  software. 

Sensor  System  Simulation  Fidelity:  During  the  abovementioned  discussions 
with  the  Ft.  Hood  troops,  they  also  expressed  the  opinion  that  the  CITV  simulation 
in  CCTT  needed  improvement,  as  did  the  overall  thermal  simulation  capabilities. 
Specifically  regarding  the  CITV,  they  felt  that  both  the  controls  and  the  display 
resolution  did  not  provide  a  realistic  simulation  of  the  actual  vehicle  system 
performance.  Again,  improvements  that  have  been  made  to  the  AGTS  CITVsystem 
may  serve  as  the  basis  for  CCTT  enhancement.  Increasing  the  overall  fidelity  of  the 
thermal  simulation  is  a  more  general  issue,  one  that  is  continuously  being 
addressed  by  simulation  enhancements. 

MCC/MC  Modifications:  We  do  not  anticipate  any  changes  to  the  MCC/MC.  It 
will  be  used  to  initialize  and  monitor  the  CCTT  equipment.  The  GIOS  will  be  used 
to  initialize,  monitor  and  control  the  gunnery  exercise  after  the  MCC/MC  has 
initialized  the  CCTT  equipment. 

Display  Resolution:  Display  resolution  was  another  issue  raised  by  the  Ft.  Hood 
troops.  They  expressed  an  inability  to  identify  targets  at  ranges  that  they  could  in 
the  vehicle  or  even  in  AGTS.  This  is  an  unexpected  finding  that  will  need  to  be 
investigated  further.  These  issues  stem  from  the  5km  target  range  required  of 
AGTS  versus  4km  for  CCTT,  and  the  relative  fidelity  of  the  reticle  simulations.  For 
purposes  of  the  gunnery  evaluation  discussed  in  paragraph  7.2,  it  may  be  possible 
to  overcome  these  issues  via  the  use  of  data  base  modeling  techniques,  such  as 
articifial  enlargement  of  targets  at  long  ranges. 

6.4.2  AGTS 

Integration  of  a  GIOS  with  AGTS  should  be  relatively  straightforward.  The  main 
issues  revolve  around  host  computer  and  PDU  modifications. 

Host  Software  Modifications:  The  primary  task  here  is  to  disable  the  10  related 
functions  from  the  host  software,  and  make  the  necessary  modifications  to  interact 
with  the  10  functions  externally  hosted  on  the  GIOS.  Also,  the  local  copy  of  the 
NLP  software  will  need  to  be  integrated,  along  with  terrain  reasoning  software  for 
automated  maneuvering  through  the  terrain  data  base. 

DIS  PDU  Modifications:  The  main  issue  here  is  addition  of  the  new  Data  PDU. 
As  described  above  under  CCTT  Integration,  this  PDU  will  include  all  of  the  crew 
compartment  switch  settings;  it  will  be  transmitted  from  the  AGTS  host  computer 
to  the  GIOS  whenever  there  is  a  change  in  the  PDU  dataset. 

7.  Potential  Follow-On  Activities 

As  mentioned  earlier,  we  recommend  a  two  phase  Proof-of-Principle  (POP) 
implementation  approach.  The  first  phase  POP  is  a  stand-alone  implementation  of 
a  prototype  GIOS;  this  is  described  in  paragraph  7.1.  Given  a  successful  first  phase, 
then  the  logical  second  phase  POP  would  be  an  integration  of  the  prototype  GIOS 
with  a  CCTT  M1A2  Qmck  Start  module  in  the  ADST II  Operational  Support 
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Facility;  this  is  described  in  paragraph  7.2. 

7.1  Stand-Alone  Prototype  Implementation 

The  purpose  of  a  stand-alone  first  phase  POP  is  to  prove  the  feasibility  of  the  GIOS 
with  respect  to  the  following: 

•  The  viability  of  NLP  in  a  noisy,  DIS  environment; 

•  The  capability  of  NLP  and  terrain  reasoning  to  automate  driver  and  loader 
functions; 

•  The  capability  of  NLP  combined  with  scoring  algorithms  and  an  intelligent 
monitoring  function  to  eliminate  the  need  for  a  dedicated  crew  station  lO  during 
platoon  gunnery  training; 

•  The  ability  to  manage  the  data  from  multiple  crew  stations  such  that  a  single  10 
can  cope  with  the  resulting  information  flow; 

•  The  adequacy  of  two  channels  of  IG  imagery; 

•  The  effectiveness  of  expressing  situation  monitor  data  in  graphical  form  and 
combining  it  with  a  plan  view  display; 

•  The  cost-effectiveness  of  a  stand-alone  DIS  compliant  GIOS;  and 

•  The  ability  to  automate  the  10  processes  well  enough  to  reduce  10  requirements 
from  8  to  1  in  a  platoon  setting. 

7.1.1  Approach 

To  accomplish  this  evaluation  we  propose  to  implement  a  prototype  GIOS  as 
described  in  Section  6.3,  “Strawman  Design”.  The  approach  is  as  follows: 

System  Specification:  the  process  begins  with  the  development  of  a  System 
Specification,  which  will  be  reviewed  with  STRICOM  prior  to  implementation. 

Technology  Interchange  Meetings:  TIM’s  will  be  conducted  on  a  regular  basis 
to  ensure  that  work  proceeds  in  IPT  fashion.  Four  TIM’s  are  proposed:  (1)  at  project 
kick-off,  (2)  at  the  conclusion  of  the  system  specification  phase,  (3)  at  the  conclusion 
of  the  design  phase,  and  (4)  after  the  system  evaluation  phase. 

Software  Development:  Software  development  is  estimated  at  two  full-time 
programmers  plus  support  from  Research  Triangle  Institute  (RTI)  for  the  NLP 
related  software  effort.  Subtasks  include  development  of  (1)  a  software  framework, 
(2)  language  parser  and  dialogue  controller  (RTI),  (3)  terrain  reasoning,  (4) 
information  management,  (5)  plan  view  display  enhancements,  and  (6)  gunner 
emulation. 

Knowledge  Base  Development:  a  knowledge  base  will  be  created  to  support 
NLP  and  performance  monitoring  requirements  for  an  M1A2  environment.  It  will 
be  done  such  that  it  can  readily  be  adapted  to  other  vehicle  types,  such  as  the 
M2/M3A3. 
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Exercise  Database/Path  Generation:  assuming  the  use  of  an  existing  visual 
database,  this  task  will  create  the  ground  paths  and  other  exercise  set-up  data 
required  to  perform  the  GIOS  evaluations. 

Integration  and  Test:  This  phase  of  the  project  brings  together  the  hardware, 
software  and  databases  into  a  complete  system. 

Evaluation:  During  this  phase  of  the  project  the  GIOS  is  evaluated  as  a  tool  to 
support  platoon  gunnery  via  the  use  of  emulated  gunners.  The  evaluation  will 
consider  the  issues  identified  in  the  beginning  of  this  Section. 

Final  Report:  A  Final  Report  will  be  prepared  describing  the  work  performed  on 
the  contract.  It  will  include  a  proposal  for  a  follow-on  POP  to  integrate  the 
prototype  GIOS  with  a  CCTT  M1A2  Quick  Start  Module  in  the  ADST II  OSF. 
Therefore  it  will  address  a  number  of  implementation  issues  in  depth,  such  as 
bandwidth  requirements,  impact  on  CCTT  host  software,  fidelity  issues  such  as  IG 
update  rate  and  resolution,  etc.  These  subjects  were  dealt  with  in  summary  form  in 
this  report  in  paragraph  6.4.1. 

7.1.2  Schedule 


The  proposed  schedule  is  shown  in  Figure  7.1-1.  It  assumes  a  start  Date  of 
November  1, 1996. 


GIOS  Prototype 

1996 

1997 

Oct 

Nov 

Dec 

Jan 

Feb 

Mar 

Apr 

May 

Jun 

Jui 

Aug 

Sept 

Contract  Start-Up  (assume  Nov.  1) 

L 

a 

Acquire  Hardware 

A- 

1 

System  Specification 

A- 

Technology  Interchange  Meetings 

O 

> 

o 

Software  Development 

-  Establish  Software  Framework 

L 

Nj — ^ 

-  Language  Parser  &  Dialogue  Controller 

L - 

- sj 

-Terrain  Reasoning 

2 

} - 

L_ 

-  Information  Manager 

— X 

7 

-  Enhance  Plan  View  Display 

zj 

^ - 

-  Gunner  Emulation 

Js - 

— 

Knowledge  Base  Development 

2 

s - 

— } 

7 

Exercise  Database/Path  Generation 

V - 

— \ 

7 

Integration  and  Test 

} 

^ - 

- \ 

7 

Evaluation 

L 

Final  Report 

B 

rl 

1 

■ 

Oct 

Nov 

Dec 

Jan 

Feb 

Mar 

Apr 

May 

Jun 

Jul 

Aug 

Sept 

Figure  7.1-1:  Prototype  Development  Schedule 


7.1.3  Budgetary  Costs 
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For  budgetary  purposes  only  we  have  estimated  the  cost  to  develop  a  prototype 
GIOS  as  $700K.  A  detailed  cost  proposal  will  be  prepared  separately.  The 
breakdown  is  as  follows: 

•  Material  Costs:  $100K 

Includes  a  Low  cost  IG  (RealSD  Pro  1400),  a  Sun  Ultra  Multi-CPU  Workstation, 
and  miscellaneous  hardware  and  software  licenses. 

•  Software  Development:  $350K 

Includes  2  full  time  software  engineers  and  a  subcontract  to  RTI  for  NLP  work. 

•  Systems:  $150K 

Includes  1  full  time  system  engineer ,  and  a  full-time  technician  for  database 
work  and  general  support. 

•  PMO:  $100K 

Includes  a  part-time  Project  Director,  contracts,  subcontracts,  and  finance 
support,  and  proposal  development. 

7.2  Prototype  Integration  with  CCTT 

Assuming  a  successful  first  phase  POP,  then  the  logical  second  phase  effort  would 
be  the  integration  of  the  prototjrpe  GIOS  with  a  CCTT  M1A2  Quick  Start  Module. 
This  phase  of  the  project  is  more  difficult  to  scope  at  this  time,  since  it  requires  a 
detailed  understanding  of  CCTT  host  software,  IG  capabilities,  and  so  forth.  Since 
the  CDF  Upgrade  DO  will  soon  be  integrating  the  CCTT  M1A2  into  the  OSF  and 
MWTB  facilities,  we  propose  to  leverage  this  work  for  Phase  2  of  GIOS.  During 
Phase  1  of  GIOS,  while  the  CCTT  M1A2  integration  effort  is  occurring,  we  will 
develop  detailed  costs  for  the  efforts  required  to  integrate  GIOS  with  the  CCTT 
environment.  A  general  description  of  the  integration  effort  that  we  foresee  at  this 
time  was  presented  in  paragraph  6.4.1.  Integration  with  AGTS  is  also  discussed; 
see  paragraph  6.4.2. 

We  anticipate  that  the  test  and  evaluation  environment  will  consist  of  the  GIOS 
networked  with  an  M1A2  module,  an  MCC/MC,  ModSAF,  and  a  data  logger,  as 
shown  in  Figure  7.2-1. 
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As  shown,  this  approach  leverages  work  that  is  currently  underway  on  the  CDF 
Upgrade  DO  to  integrate  an  M1A2  and  M2A2  into  the  OSF.  Note  that  a  Translator 
is  being  implemented  to  translate  CCTT  PDUs  between  DIS  2.0.4  r  and  DIS  2.0.4 
and  DIS  2.0.3.  The  Hub  bridges  the  different  media  (FDDI  and  ethernet). 


The  evaluation  process  will  assess  the  capabilities  of  the  GIOS  in  the  CCTT 
environment  as  follows: 


•  Ability  to  train  precision  gunnery  with  or  without  the  loader  and  driver; 

•  Fidelity  of  the  modified  system  in  terms  of  update  rate,  resolution,  etc.; 

•  Impact  on  host  computer  hardware  and  software; 

•  Interoperability  issues  with  respect  to  databases,  PDUs,  and  bandwidth;  and 

•  Cost  effectiveness  -  i.e.,  the  cost  in  terms  of  manpower  and  equipment  to  retrofit 
GIOS  devices  to  fielded  CCTT  systems. 

7.3  Extensions  to  Other  Applications 

GIOS,  as  an  independent,  reconfigurable,  DIS-compliant  workstation,  offers  a 
flexible  platform  that  can  support  other  functional  capabilities  within  the  presently 
defined  domain  of  Combined  Arms  Tactical  Trainers  (CATT)  simulators  and 
precision  gunnery  trainers,  as  well  as  extension  to  other  training  domains.  It 
provides  the  capability  for  the  generation  and  display  of  high  fidelity  images  and 
traditional  computer  graphics,  logging  of  PDU  data,  network  voice  communications, 
and  simulation  and  training  exercise  control.  It  can  support  either  real-time  or 
after-action  simulation  activities.  The  inherent  capabilities  and  flexibility  (through 
software  modifications)  of  GIOS  make  it  an  attractive  solution  to  a  wide  range  of 
DIS  applications.  Some  of  these  potential  applications  were  identified  in  the  GIOS 
proposal  and  are  discussed  in  the  following  paragraphs. 
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It  is  clear  that  extension  of  GIOS  to  the  indirect  fire  (FSCATT)  and  air  defense 
(ADCATT)  domains  will  require  an  assessment  of  requirements  for  instructor 
training  support  in  the  same  manner  as  has  been  conducted  for  the  AGTS  and 
CCTT  systems.  Without  such  a  clear  statement  of  requirements,  it  is  impossible  to 
adequately  assess  the  ability  of  GIOS  as  currently  configured  to  meet  system 
training  needs.  However,  inasmuch  as  the  systems  are  DIS-compliant  simulators, 
integrated  into  an  overall  network  of  CATT-family  simulators  -  i.e.,  CCTT, 

FSCATT,  AVCATT,  ADCATT,  and  ENCATT  (Engineering  CATT)  -  GIOS’s  basic 
capabilities  should  be  able  to  support  the  majority  if  not  all  required  functionality. 
The  PVD  can  represent  the  overall  simulation  environment  and  provide  access  to 
information  on  individual  simulation  assets.  The  image  generation  capability  can 
reproduce  the  visual  perspective  and  scene  content  from  any  entity  or  independent 
location  in  the  database.  Personnel  operating  GIOS  can  communicate  over  the 
network  with  any  asset  configured  with  a  DIS  radio/receiver.  Specific  issues 
regarding  unique  software  capabilities,  quantities  of  GIOS  workstations  to  support 
a  simulation,  number  of  displays,  etc.  await  the  detailed  analyses.  Since  this  is 
beyond  the  scope  of  this  current  effort,  a  general  description  of  the  FSCATT  and 
ADCATT  systems  is  provided  to  support  our  initial  assessment  of  GIOS’s  ability  to 
support  them. 

Fire  Support  Combined  Arms  Tactical  Trainer  (FSCATT) 

The  FSCATT  is  a  distributed-process,  networked  simulation  system  which  will 
provide  combined  arms  collective  training  of  Field  Artillery  units.  FSCATT  consists 
of  a  family  of  five  devices  that  provides  battery-level  initial  and  sustainment 
training  of  Field  Artillery  gunnery  teams  (Forward  Observer,  Fire  Direction  and 
Firing  Battery  personnel),  giving  them  feedback  on  their  proficiency  while 
conserving  fuel  and  ammunition.  FSCATT  Phase  II  provides  the  capability  for  the 
closed  loop  system  to  interoperate  with  other  CATT  systems.  Additional  manned 
modules  enable  howitzer  batteries  and  Battalion  Staffs  to  conduct  tactical  fire 
support  operations  in  a  combined  arms,  computer  simulated  environment.  Using 
common  CATT  component  and  DIS  technology,  FSCATT  manned  modules  are 
capable  of  stand-alone  combined  arms  operations  using  SAF  and  emulator 
workstations.  It  is  also  capable  of  conducting  training  with  other  systems  of  the 
CATT  family. 

GlOS-related  requirements  for  the  FSCATT  system  are  to  monitor  student 
activities,  record  performance  and  produce  after  action  review  for  individual  skills, 
crew  drills,  and  partial  unit  drills  in  executing  all  manner  of  artillery  fire  missions. 

Air  Defense  Combined  Arms  Tactical  Trainer  (ADCATT) 

The  ADCATT  is  a  distributed  processing,  networked  simulation  system  which 
allows  short  range  Air  Defense  (SHORAD)  units  to  train  collective  tasks  associated 
with  the  support  of  Mechanized  and  Armor  Maneuver  units.  It  consists  of  mobile 
platoon  sets  of  the  Avenger  or  M2  BFV  Stinger  Under  Armor.  Emulator 
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workstations  represent  the  Forward  Area  Air  Defense  (FAAD)  Command  and 
Control  network.  Combat  Support  and  Combat  Service  Support  functions  of  the 
combined  arms  battlefield  are  included  in  each  platoon  set.  SAF  workstations  can 
provide  OPFOR  and  BLUFOR  entities  in  a  stand-alone  operational  mode  or 
ADCATT  can  be  networked  to  operate  with  other  CATT  systems.  It  can  be 
anticipated  that  requirements  for  crew  performance  monitoring  and  AAR  will  be 
similar  for  ADCATT  as  for  FSCATT  and  other  CATT  systems. 

7.3.2  Higher  Echelons 

Precision  gunnery  simulators  were  originally  developed  to  support  individual  and 
crew  level  training.  The  Conduct  of  Fire  Trainer  (COFT)  pioneered  the  use  of 
objective  scoring  methods  for  gunnery  training.  A  three  dimensional  training 
matrix  was  developed  to  create  a  logical  framework  for  progressively  more  difficult 
training  exercises.  Figure  7. 3. 2-1  illustrates  a  generalized  form  of  the  training 
matrix. 


Enemy 

Capability 


A  progression  of  enemy  forces  from  single  vehicles 
at  short  range  to  multiple  units  at  long  range 


Environment 


A  progression  of  visibility  conditions  from  unlimited 
visibility  to  limited  visibility  with  haze  and  thermal 
clutter  at  various  times  of  day 


Mission 


A  progression  of  missions  for  a  given  echelon  with  the 
ownship/ownunit  engaging  stationary  and  moving 
vehicles/units 


Figure  7. 3. 2-1:  Generalized  Training  Matrix 

The  axes  of  the  three  dimensional  matrix  represent  mission  objectives, 
environmental  conditions,  and  enemy  capabilities,  as  shown.  Exercises  are 
organized  as  cells  within  the  matrix  with  increasing  levels  of  difficulty  along  each 
axis.  Progression  through  matrix  exercises  is  determined  by  the  proficiency  of  the 
crew.  As  the  crew  demonstrates  successful  performance,  conditions  are 
automatically  changed,  resulting  in  more  difficult  exercises.  Changing  conditions 
include  number  of  targets,  range  to  target,  visibility,  and  malfunctions.  A  major 
benefit  of  this  automated  scoring  methodology  is  that  crews  are  trained  against 
established  standards  which  are  objectively  scored  by  the  simulator  system  [ref  40]. 

With  the  advent  of  the  PGT  and  its  successor  AGTS,  platoon  level  training  has  been 
added  to  the  precision  gunnery  training  regime.  Platoon  exercises  begin  with 
simple  offensive  and  defensive  missions  against  proficient  enemies.  They  then 
progress  to  complex  missions  against  a  combat  ready  enemy.  The  platoon  exercises 
are  conceptually  organized  into  a  three  dimensional  matrix.  This  permits  the 
change  of  conditions  in  any  one  of  three  directions  based  on  performance. 

Platoon  gunnery  training  incorporates  within  it  a  limited  amount  of  tactical 
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training.  The  platoon  leader  needs  to  make  tactical  decisions  within  the  context  of 
the  given  gunnery  exercise.  However,  the  issue  of  scoring  tactical  performance  in  a 
hybrid  tactical-gunnery  environment  has  yet  to  be  fully  addressed.  This  becomes  a 
significant  issue  if  the  training  regime  is  notched  up  another  echelon  to  Company  or 
Team  levels. 

The  natural  evolutionary  step  would  be  to  extend  the  training  matrix  methodology 
to  the  tactical  domain.  Figure  7. 3. 2-2  illustrates  this  extended  concept  in  notional 
form. 

Enemy 


Gunnery _ 

I  Tactics 


Figure  7. 3. 2-2:  Tactical  Extension  of  the  Training  Matrix 

For  prior  and  current  systems,  the  10  judges  whether  the  tactics  employed  for  a 
given  exercise  are  appropriate.  The  challenge  for  the  hybrid  gunnery/tactical 
system  is  in  determining  how  to  apply  automated,  computer  based  scoring  methods 
to  augment  subjective  human  judgments.  It  is  probably  not  feasible  nor  desirable 
to  completely  eliminate  human  judgment  from  the  evaluation  process;  however, 
even  a  partial  solution  would  be  beneficial  as  an  aid  to  the  10. 

RFP’s  released  by  some  overseas  buyers  have  expressed  an  interest  in  hybrid 
tactical/gunnery  training  systems  that  extend  to  Company  level.  Furthermore, 
briefings  by  TSM  CATT  have  presented  the  notion  of  a  “Tactical  Proficiency  Matrix” 
that  looks  very  similar  to  our  notional  concept  shown  above  [ref  41].  A  follow-on 
study  could  explore  these  concepts  in  depth,  and  develop  a  candidate  scoring 
methodology  for  combined  tactical/gunnery  training. 

7.3.3  AAR 

According  to  the  Army  Master  Plan  for  DIS  [ref  39] ,  one  of  the  required  capabilities 
that  DIS  must  provide  to  the  training  community  is  an  after  action  review  (AAR). 
Specifically,  the  plan  calls  for  an  AAR  capability  which  (from  page  III-6): 
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•  Automatically  synchronizes  multimedia  (voice,  video) 

•  Provides  instantaneous  feedback/replay  upon  demand  to  capture  all  events 
defined  by  the  user  as  critical 

•  Supports  customization  to  meet  user  defined  needs 

•  Captures  data  on  the  network  which  is  interactive  information,  and  should 
also  record  local  information  within  the  simulations/simulators 

•  Even  though  the  focus  of  the  exercises  may  be  on  collective  training,  data  on 
individual  and  crew  performance  should  also  be  recorded 

•  Has  the  capability  to  rapidly  process  a  wide  variety  of  data  and  produce 
meaningful  presentations  of  desired  information. 

The  basic  GIOS  capabilities  are  consistent  with  these  as  well  as  with  existing  ACTS 
and  CCTT  AAR  requirements  and  implementations.  Since  these  latter 
requirements  are  more  completely  defined  and  instantiated  in  proposed  or  existing 
designs,  the  ability  of  GIOS  to  support  the  AGTS  and  CCTT  AARs  is  assessed  in  the 
following  paragraphs. 

AGTS  PAAR 

The  current  AGTS  PAAR  (prebrief  and  AAR)  concept  (for  platoon  training  only; 
crew  debrief  consists  of  instructor  review  of  a  printed  crew  performance  summary) 
includes  a  workstation  with  a  data  logger  that  can  regenerate  voice  communications 
PDUs,  a  PVD  that  can  display  vehicle  movements,  firing  events,  etc.,  and  a 
capability  to  generate  graphic  displays  of  general  platoon  gunnery  performance 
statistics.  Crewstation  sight  replay  and  stealth  views  are  not  provided.  The  AGTS 
PAAR  is  intended  for  use  solely  as  a  pre-  and  post-exercise  asset;  no  real-time 
requirements  currently  exist.  Instructors  post-process  the  exercise  to  identify  and 
mark  significant  events  and  otherwise  construct  the  AAR.  PVD  graphics,  voice 
communications,  and  charts/graphs  indicating  platoon  performance  statistics  are 
displayed  to  the  platoon  on  a  PAAR  CRT  display  during  the  AAR. 

Given  these  requirements,  it  is  clearly  within  the  proposed  capabilities  of  GIOS  to 
support  these  features.  In  fact,  the  IG  is  not  required  to  meet  the  AGTS 
requirements.  For  AGTS,  GIOS  represents  an  opportunity  to  enhance  the  AAR 
capabilities  to  include  crew  performance  features  such  as  sight  replay  and  stealth 
view  generation  that  users  have  requested  for  inclusion  in  an  AAR. 
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CCTTAAR 

The  CCTT  AAE  workstation  allows  the  operator  to  monitor,  record,  playback, 
analyze,  and  report  on  exercises.  The  operator  can  see  the  entire  battlefield,  access 
the  current  status  of  vehicles,  and  listen  to  voice  communications.  These 
capabilities  are  available  both  during  exercises  and  at  playback.  During  an 
exercise,  the  operator  can  make  verbal  and  time-stamped  textual  notes  that  are 
available  during  playback.  AAR  data  analysis  and  reporting  allows  the  operator  to 
analyze  the  exercise  by  providing  statistical  summaries  of  exercise  data.  Three 
display  monitors  provide  an  IG-created  line-of-sight  view  that  can  operate  in  one  of 
three  modes:  1)  Slaved  mode,  which  displays  the  sight  or  visual  display  for  either 
the  gunner  or  commander’s  view  for  any  selected  manned  module,  2)  Independent 
mode,  in  which  the  operator  has  the  capability  to  position  the  eyepoint  an5rwhere  in 
the  gaming  area  from  ground  level  up  to  an  altitude  of  300  meters,  and  3)  Tether 
mode,  in  which  the  eyepoint  is  tethered  (direction  and  velocity)  to  any  vehicle  in  the 
database. 

In  addition  to  these  display  monitors,  the  AAR  console  also  has  a  PVD  which  gives 
the  operator  an  overall  view  of  the  battlefield.  A  separate  menu  display  is  also 
provided  to  allow  the  operator  to  control  AAR  functions. 

Again,  these  AAR  requirements  are  consistent  with  the  basic  GIOS  concept.  The 
basic  capabilities  required  for  the  CCTT  AAR  -  IG-generated  stealth  view,  PVD, 
voice  communications,  miscellaneous  text/graphics  display  -  are  all  provided  by 
GIOS.  The  software  controlling  the  AAR  processes  is  of  course  unique  to  CCTT  and 
its  interfaces,  but  the  overall  requirements  could  be  instantiated  in  a  GIOS- 
configured  console. 

In  summary,  the  Army’s  general  requirements  for  a  DIS  AAR  could  be  realized  in  a 
GlOS-derived  console,  including  the  integration  of  existing  CATT  and  AGTS  AAR 
stations. 

7.3.4  MCC/MC 

The  CCTT  master  control  and  maintenance  consoles  (MCC/MC)  are  supported  by 
the  same  software  CSCI  (computer  system  configuration  item),  although  two 
separate  consoles  may  still  be  needed  for  hardware  redundancy  and  on-line 
troubleshooting  during  exercise  conduct.  Generally,  the  MCC/MC  provides  the 
capabilities  to  allow  the  operator(s)  to  initialize,  monitor,  and  control  the  exercises 
and  to  monitor  and  control  the  CCTT  physical  network,  software  maintenance,  and 
fault  localization.  Detailed  MCC/MC  requirements  and  capabilities  were  presented 
in  Section  5.2.3. 1. 

The  primary  operational  use  of  the  MCC  functions  is  for  the  initial  configuration, 
parameter  selection,  and  initiation  of  the  CCTT  training  exercise.  During  exercise 
conduct,  the  MCC  operator  has  very  little  to  do,  based  on  personal  communications 
with  CCTT  personnel.  However,  there  are  several  real-time  capabilities  that  the 
MCC  provides  on  demand,  such  as  changing  exercise  parameters  (weather 
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conditions,  time  of  day,  fuel  and  ammunition  loads,  vehicle  locations  and 
orientations,  vehicle  status,  etc.),  reinitialization,  reconstitution,  and  pause/resume. 
The  execution  of  all  of  the  MCC  functions  is  controlled  by  the  MCC  software  in 
response  to  operator  intervention  through  the  MCC  software-user  interface.  This 
interface  is  a  standard  GUI  format  supplemented  by  a  same-display  PVD  to  assist 
in  vehicle  location  and  placement.  No  image  generation  capability  is  required. 

The  implications  of  these  requirements  for  GIOS  are  similar  to  those  previously 
discussed  for  the  AGTS  PAAR  -  the  GIOS  capabilities  far  exceed  those  needed  to 
implement  the  required  functions.  What  is  required  is  basically  a  workstation  to 
support  the  necessary  CCTT  or  equivalent  software,  network,  and  other 
hardware/display  interfaces.  The  primary  issues  are  in  terms  of  compatibility, 
storage  capacity,  and  memory.  There  is  no  inherent  limitation  in  GIOS  restricting 
it  from  being  extended  to  the  MCC/MC  application. 

8.  Summary 

This  Feasibility  Analysis  Study  Final  Report  has  presented  the  results  of  an  ADST 
II  study  effort  conducted  to  examine  the  feasibility  of  a  Generic  Instructor  Operator 
Station  (GIOS)  for  use  on  US  Army  engagement  simulators.  The  effort  has  focused 
on  three  specific  STRICOM  programs:  AGTS,  CCTT,  and  AVCATT,  with  emphasis 
on  the  first  two  due  to  a  lack  of  hard  requirements  data  for  AVCATT.  The  approach 
taken  has  been  to  re-engineer  the  AGTS  lOS  such  that  it  could  be  added  to  CCTT  to 
provide  structured  gunnery  training,  or  to  AGTS  as  a  DIS  compatible  device  to 
support  reducing  instructor  manpower  requirements  during  platoon  gunnery 
training.  Further,  the  study  addressed  the  inclusion  of  semi-automated  Instructor 
Operator  (10)  functions  to  give  each  10  a  greater  span  of  control,  again  with  the 
goal  of  significantly  reducing  10  manpower  requirements  for  platoon  training  while 
maintaining  current  crew-level  training  capabilities.  Natural  Language  Processing 
was  shown  to  be  a  key  technology  required  to  achieve  this  level  of  manpower 
reduction. 

The  study  concluded  with  a  preliminary  design  concept  for  the  GIOS  and  a  phased 
approach  to  implement  the  design.  The  first  phase  develops  a  stand-alone  console; 
the  second  phase  integrates  it  with  a  CCTT  manned  module.  Finally,  an 
assessment  was  made  of  the  viability  of  extending  the  GIOS  design  concept  to  other 
CATT  training  systems,  to  higher  echelons,  and  to  other  functional  training 
components,  such  as  an  AAR  and  MCC/MC  station. 
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